glassfish
  1. glassfish
  2. GLASSFISH-3032

TransactionAttributeType of REQUIRES_NEW doesn't create transaction with "FOR UPDATE" select

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 9.1pe
    • Fix Version/s: 9.1pe_dev
    • Component/s: entity-persistence
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      3,032

      Description

      Using glassfish V2 Beta2 using PostgreSQL 8.2
      When using a named query within a function marked as
      @TransactionAttributeType:REQUIRES_NEW using the query hint
      "toplink.pessimistic-lock" with a value of "Lock", the container doesn't create
      a new transaction as is necessary.

      eg:

      @Entity
      @Table(name = "a_table")
      @NamedQuery(name = "selectLocked", query = "SELECT t FROM Table t WHERE t.id = :id")
      public class Table implements Serializable {
      ...
      }

      @TransactionAttribute(value=TransactionAttributeType.REQUIRES_NEW)
      public void callLockedQuery(){
      TableEntity val=(TableEntity)em.createNamedQuery("selectLocked")
      .setHint("toplink.pessimistic-lock","Lock")
      .setParameter("id", 234)
      .getSingleResult();
      // do something with the entity
      }

      The query is correctly created with "FOR UPDATE" (with a modified PostgreSQL
      platform file which appends the correct string - the original appends "FOR
      UPDATE OF *" which is illegal syntax in PostgreSQL) appended but because the
      query isn't run within a transaction, the rows on the database aren't locked.

      The only way to get a transaction to be created is to use a native query (named
      or not) which results in the correct behaviour.

      Finally if a named native query is used with a resultClass instead of a
      resultSetMapping, then periodically a transaction isn't created as described
      above. This seems to occur the first time the function is called following
      deplouyment.

        Activity

        Hide
        gfbugbridge added a comment -

        <BT6560302>

        Show
        gfbugbridge added a comment - <BT6560302>
        Hide
        tware added a comment -

        Investigating

        Show
        tware added a comment - Investigating
        Hide
        tware added a comment -

        Is it possible for a test case to be provided.

        I have discovered a potential cause of this issue, but so far do not have a
        recreation that I can use to confirm the fix.

        Show
        tware added a comment - Is it possible for a test case to be provided. I have discovered a potential cause of this issue, but so far do not have a recreation that I can use to confirm the fix.
        Hide
        jsl123 added a comment -

        Created an attachment (id=942)
        Test case

        Show
        jsl123 added a comment - Created an attachment (id=942) Test case
        Hide
        jsl123 added a comment -

        Test case attached.

        Also, if you use bean managed transactions you get the same problem even when
        Usertransaction.begin() is called - see test.

        The test case is a self contained ejb-module with a junit test done as a
        netbeans project.

        Uncomment/comment various bits of the test to enable/disable bean managed
        transaction. Also code added to try and force a transaction to occur..

        Requires a datasource registered on the server as jdbc/DB.

        Note that if you use this with PostgreSQL, there is a bug in the implementation
        of the DatabasePlatform class, it appends "FOR UPDATE OF *" which is unsupported
        by postgres.

        Show
        jsl123 added a comment - Test case attached. Also, if you use bean managed transactions you get the same problem even when Usertransaction.begin() is called - see test. The test case is a self contained ejb-module with a junit test done as a netbeans project. Uncomment/comment various bits of the test to enable/disable bean managed transaction. Also code added to try and force a transaction to occur.. Requires a datasource registered on the server as jdbc/DB. Note that if you use this with PostgreSQL, there is a bug in the implementation of the DatabasePlatform class, it appends "FOR UPDATE OF *" which is unsupported by postgres.
        Hide
        tware added a comment -

        Issue number: 3032
        Obtained from: TopLink
        Submitted by: Tom Ware
        Reviewed by: Gordon Yorke

        Solves issues where ReportQuery with pessimistic locking do not automatically
        cause the UnitOfWork to use the write connectin

        Tested with entity-persistence-tests, QuickLook and Oracle-internal tests

        Added EntityManagerJunitTestSuite.testPessimisticLockHintStartsTransaction()

        Show
        tware added a comment - Issue number: 3032 Obtained from: TopLink Submitted by: Tom Ware Reviewed by: Gordon Yorke Solves issues where ReportQuery with pessimistic locking do not automatically cause the UnitOfWork to use the write connectin Tested with entity-persistence-tests, QuickLook and Oracle-internal tests Added EntityManagerJunitTestSuite.testPessimisticLockHintStartsTransaction()
        Hide
        sherryshen added a comment -

        Verified that the fix works on Oracle, but not on Postgres and Derby.
        Filed Issue 3125 for the remaining error.

        Show
        sherryshen added a comment - Verified that the fix works on Oracle, but not on Postgres and Derby. Filed Issue 3125 for the remaining error.

          People

          • Assignee:
            tware
            Reporter:
            jsl123
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: