Uploaded image for project: 'OpenJPA'
  1. OpenJPA
  2. OPENJPA-2614

First rollback after application start does not work under certain circumstances

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.4.0
    • 3.2.1
    • jpa
    • None

    Description

      Rollback is not complete under the following circumstances:

      1. Entites must use a sequence generator with GenerationType.SEQUENCE
      2. It is the first rollback after application start
      3. You have to flush successfully during the creation of entities
      4. The transaction is rolled back during commit because of a constraint violation

      Expected result: Nothing remains in the database that is created during the transaction

      Actual result: Entites created before the flush are persisted (i.e. not rolled back)

      An example project is attached. It shows the described problem when executing the test.

      Attachments

        1. jpa-test.zip
          14 kB
          Tim Gödde

        Activity

          struberg Mark Struberg added a comment -

          We now do open a new Connection for those operations.

          struberg Mark Struberg added a comment - We now do open a new Connection for those operations.

          Commit c5b97348fcfcb77d1a0c00813bc4c18bf85140f7 in openjpa's branch refs/heads/master from Mark Struberg
          [ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=c5b9734 ]

          OPENJPA-2614 run ALTER SEQUENCE in a separate tx

          Quite a lot databases force a commit on DDL changes.
          For sequences we try to run an ALTER SEQUENCE to make the sequence
          reflect the allocationSize. Doing this will commit all outstanding open
          DB changes in Oracle and a few other databases.
          We now open a new connection.

          jira-bot ASF subversion and git services added a comment - Commit c5b97348fcfcb77d1a0c00813bc4c18bf85140f7 in openjpa's branch refs/heads/master from Mark Struberg [ https://gitbox.apache.org/repos/asf?p=openjpa.git;h=c5b9734 ] OPENJPA-2614 run ALTER SEQUENCE in a separate tx Quite a lot databases force a commit on DDL changes. For sequences we try to run an ALTER SEQUENCE to make the sequence reflect the allocationSize. Doing this will commit all outstanding open DB changes in Oracle and a few other databases. We now open a new connection.
          jtestori Johannes Testori added a comment - - edited

          We encountered the same problem in our application using OpenJPA 3.2. After some debugging we found out that before the first allocation of a sequence value OpenJPA executes an ALTER SEQUENCE-statement. Since this is a DDL statement, some databases (e.g. Oracle) issue an implicit commit, so no matter if you commit or rollback afterwards, all changes that have been flushed before ALTER SEQUENCE will be committed in the database. So this problem can not only arise at the first rollback, but at the first use of every single sequence that is defined in an entity.

          A possible solution could be the use of an independent transaction for the ALTER SEQUENCE-statement.

          jtestori Johannes Testori added a comment - - edited We encountered the same problem in our application using OpenJPA 3.2. After some debugging we found out that before the first allocation of a sequence value OpenJPA executes an ALTER SEQUENCE-statement. Since this is a DDL statement, some databases (e.g. Oracle) issue an implicit commit, so no matter if you commit or rollback afterwards, all changes that have been flushed before ALTER SEQUENCE will be committed in the database. So this problem can not only arise at the first rollback, but at the first use of every single sequence that is defined in an entity. A possible solution could be the use of an independent transaction for the ALTER SEQUENCE-statement.

          People

            struberg Mark Struberg
            tim.goedde Tim Gödde
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: