Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-M2
    • Fix Version/s: 2.0.0-M2
    • Component/s: jpa
    • Labels:
      None

      Description

      This task is to provide support for the lock timeout hint on applicable interface methods. OpenJPA currently supports the openjpa.LockTimeout property. This support will be extended to allow more granular configuration at the method level, where applicable. The pattern used for specifying lock modes at a method level should be considered for extension or as a guide.

        Issue Links

          Activity

          Jeremy Bauer created issue -
          Hide
          Donald Woods added a comment -

          Looks like the existing implementation (not defined in JPA 1.0 Spec and OpenJPA specific) is using setQueryTimeout() in PessimisticLockManager, which is a client side JDBC timeout function, while lock timeouts are implemented in the DB server. See -
          DB2 - http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r0011874.htm
          MS SQL - http://msdn.microsoft.com/en-us/library/aa213032(SQL.80).aspx
          Derby - config property - http://db.apache.org/derby/docs/dev/devguide/cdevconcepts16400.html
          Oracle - LOCKWAIT on the connection or on the DB
          Also, the following discussion gives a good overview of the two and why apps should use both to handle unreliable network conditions -
          http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/95755534-bbef-4c2c-afa4-b80ca2a2c333/

          Show
          Donald Woods added a comment - Looks like the existing implementation (not defined in JPA 1.0 Spec and OpenJPA specific) is using setQueryTimeout() in PessimisticLockManager, which is a client side JDBC timeout function, while lock timeouts are implemented in the DB server. See - DB2 - http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/r0011874.htm MS SQL - http://msdn.microsoft.com/en-us/library/aa213032(SQL.80).aspx Derby - config property - http://db.apache.org/derby/docs/dev/devguide/cdevconcepts16400.html Oracle - LOCKWAIT on the connection or on the DB Also, the following discussion gives a good overview of the two and why apps should use both to handle unreliable network conditions - http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/95755534-bbef-4c2c-afa4-b80ca2a2c333/
          Hide
          Donald Woods added a comment -

          Do we need to support the old behavior of using setQueryTimeout() for lock timeout as a compatibility option?

          Show
          Donald Woods added a comment - Do we need to support the old behavior of using setQueryTimeout() for lock timeout as a compatibility option?
          Show
          Donald Woods added a comment - For Oracle tables/schemas - http://www.oracle.com/technology/pub/articles/oracle-database-11g-top-features/11g-schemamanagement.html
          Hide
          Donald Woods added a comment -

          DB2 uses "SET CURRENT LOCK TIMEOUT = <secs>" for all statements on the current connection.

          Show
          Donald Woods added a comment - DB2 uses "SET CURRENT LOCK TIMEOUT = <secs>" for all statements on the current connection.
          Hide
          Albert Lee added a comment -

          FYI... I find the following in the Derby reference.

          http://db.apache.org/derby/docs/10.1/ref/refderby.pdf

          SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY
          Use the SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY system procedure to set or delete the value of a property of the database on the current connection. If "VALUE" is not null, then the property with key value "KEY" is set to "VALUE". If "VALUE" is null, then the property with key value "KEY" is deleted from the database property set.

          Syntax
          SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY(IN KEY VARCHAR(128),IN VALUE VARCHAR(32672))
          This procedure does not return any results.
          JDBC example
          Set the derby.locks.deadlockTimeout property to a value of 10:

          CallableStatement cs = conn.prepareCall
          ("CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?, ?)");
          cs.setString(1, "derby.locks.deadlockTimeout");
          cs.setString(2, "10");
          cs.execute();
          cs.close();

          SQL example
          Set the derby.locks.deadlockTimeout property to a value of 10:
          CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY
          ('derby.locks.deadlockTimeout', '10');

          java.sql.Statement
          Derby does not implement the following JDBC 1.2 methods of java.sql.Statement:
          • cancel
          • setEscapeProcessing
          • setQueryTimeout

          Show
          Albert Lee added a comment - FYI... I find the following in the Derby reference. http://db.apache.org/derby/docs/10.1/ref/refderby.pdf SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY Use the SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY system procedure to set or delete the value of a property of the database on the current connection. If "VALUE" is not null, then the property with key value "KEY" is set to "VALUE". If "VALUE" is null, then the property with key value "KEY" is deleted from the database property set. Syntax SYSCS_UTIL.SYSCS_GET_DATABASE_PROPERTY(IN KEY VARCHAR(128),IN VALUE VARCHAR(32672)) This procedure does not return any results. JDBC example Set the derby.locks.deadlockTimeout property to a value of 10: CallableStatement cs = conn.prepareCall ("CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?, ?)"); cs.setString(1, "derby.locks.deadlockTimeout"); cs.setString(2, "10"); cs.execute(); cs.close(); SQL example Set the derby.locks.deadlockTimeout property to a value of 10: CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY ('derby.locks.deadlockTimeout', '10'); java.sql.Statement Derby does not implement the following JDBC 1.2 methods of java.sql.Statement: • cancel • setEscapeProcessing • setQueryTimeout
          Hide
          Pinaki Poddar added a comment -

          How about refactoring setTimeout() from Select to to DBDictionary?
          Then we can add database specific details incremental way as Albert's & Donald's (and others) research solidifies the exact techniques for each database.

          Show
          Pinaki Poddar added a comment - How about refactoring setTimeout() from Select to to DBDictionary? Then we can add database specific details incremental way as Albert's & Donald's (and others) research solidifies the exact techniques for each database.
          Hide
          Donald Woods added a comment -

          Albert, Derby 10.2 has full support for Statement.setQueryTimeout() and I have verified that it is working as part of OPENJPA-878 (can't say the same for DB2 9.5.3a on WinXp....)

          Show
          Donald Woods added a comment - Albert, Derby 10.2 has full support for Statement.setQueryTimeout() and I have verified that it is working as part of OPENJPA-878 (can't say the same for DB2 9.5.3a on WinXp....)
          Hide
          Albert Lee added a comment -

          It would be good to support the lock timeout the way it is supposed to work. To do this properly, it will be db specific and hence DBDictionary needs to reflect this capability, if supported by the db.

          Donald, thanks for verifying the timeout feature in 10.2. We need to update the "Supported Databases" section in the manual, either: bump up the support level to 10.2 or add a known limitation describe the query timeout will NOT work if 10.1 is used.

          Albert Lee.

          Show
          Albert Lee added a comment - It would be good to support the lock timeout the way it is supposed to work. To do this properly, it will be db specific and hence DBDictionary needs to reflect this capability, if supported by the db. Donald, thanks for verifying the timeout feature in 10.2. We need to update the "Supported Databases" section in the manual, either: bump up the support level to 10.2 or add a known limitation describe the query timeout will NOT work if 10.1 is used. Albert Lee.
          Jeremy Bauer made changes -
          Field Original Value New Value
          Assignee Albert Lee [ allee8285 ]
          Pinaki Poddar made changes -
          Link This issue is related to OPENJPA-878 [ OPENJPA-878 ]
          Albert Lee made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          Albert Lee added a comment -

          Initial code drop to support hints in FetchConfiguration and FetchPlan, which are used by em interface methods that take a Map of hints/properties apply only to the the method invocation.

          Show
          Albert Lee added a comment - Initial code drop to support hints in FetchConfiguration and FetchPlan, which are used by em interface methods that take a Map of hints/properties apply only to the the method invocation.
          Albert Lee made changes -
          Attachment OPENJPA_957.patch [ 12403583 ]
          Hide
          Albert Lee added a comment -

          This is a summary of the design points for the Query/EntityManager hint supports :

          • Based on property Map<String,Object> definition, value of appropriate types and corresponding plugin aliases are valid property hint values. (E.g.

          props.put("openjpa.FetchPlan.Isolation", "serializable");
          props.put("openjpa.FetchPlan.Isolation", Connection.TRANSACTION_READ_UNCOMMITTED);
          props.put("openjpa.FetchPlan.Isolation", String.valueOf(Connection.TRANSACTION_READ_UNCOMMITTED));

          • Hints specified in Query or EntityManager interface methods become effective when the corresponding functions are applied not when the hint is being set.. This means semantics (e.g. transaction) requirements for a hint to be compliant is verified when the function is applied not when the hint is set.
          • FetchPlan processes hints that is specific to FetchPlan interface (E.g. LockMode to LockLevel type conversion) and passes the rest to FetchConfiguration for processing. FetchConfiguration handles type conversion and alias processing.
          • Query.setHint() will not throw exception if hint is not recognized and is silently ignored.
          • If multiple hints with different prefixes of similar property are specified in the same property map in the Query and EntityManager interface methods (i.e. openjpa., openjpa.jdbc., openjpa.FetchPlan.* and javax.persistence.* ) the following precedence (from high to low) applies:
            1, javax.persistence.*
            2. openjpa.FetchPlan.*
            3. openjpa.jdbc.*
            4. openjpa.*
            (e.g. javax.persistence.lock.timeout overrides openjpa.FetchPlan.LockTimeout overrides openjpa.LockTimeout)

          Albert Lee.

          Show
          Albert Lee added a comment - This is a summary of the design points for the Query/EntityManager hint supports : Based on property Map<String,Object> definition, value of appropriate types and corresponding plugin aliases are valid property hint values. (E.g. props.put("openjpa.FetchPlan.Isolation", "serializable"); props.put("openjpa.FetchPlan.Isolation", Connection.TRANSACTION_READ_UNCOMMITTED); props.put("openjpa.FetchPlan.Isolation", String.valueOf(Connection.TRANSACTION_READ_UNCOMMITTED)); Hints specified in Query or EntityManager interface methods become effective when the corresponding functions are applied not when the hint is being set.. This means semantics (e.g. transaction) requirements for a hint to be compliant is verified when the function is applied not when the hint is set. FetchPlan processes hints that is specific to FetchPlan interface (E.g. LockMode to LockLevel type conversion) and passes the rest to FetchConfiguration for processing. FetchConfiguration handles type conversion and alias processing. Query.setHint() will not throw exception if hint is not recognized and is silently ignored. Hints specified in different run-time configuration follow the rules defined in "2. Runtime Configuration" ( http://openjpa.apache.org/builds/latest/docs/manual/ref_guide_conf_specify.html ) If multiple hints with different prefixes of similar property are specified in the same property map in the Query and EntityManager interface methods (i.e. openjpa. , openjpa.jdbc. , openjpa.FetchPlan.* and javax.persistence.* ) the following precedence (from high to low) applies: 1, javax.persistence.* 2. openjpa.FetchPlan.* 3. openjpa.jdbc.* 4. openjpa.* (e.g. javax.persistence.lock.timeout overrides openjpa.FetchPlan.LockTimeout overrides openjpa.LockTimeout) Albert Lee.
          Donald Woods made changes -
          Link This issue relates to OPENJPA-991 [ OPENJPA-991 ]
          Albert Lee made changes -
          Attachment OPENJPA_957.patch [ 12403583 ]
          Hide
          Albert Lee added a comment -

          Add more clean up, refactoring and test paths.

          Show
          Albert Lee added a comment - Add more clean up, refactoring and test paths.
          Albert Lee made changes -
          Attachment OPENJPA_957.patch [ 12403845 ]
          Albert Lee made changes -
          Attachment OPENJPA_957.patch [ 12403845 ]
          Hide
          Albert Lee added a comment -

          Rework based on code review comments and suggestions.

          Albert Lee.

          Show
          Albert Lee added a comment - Rework based on code review comments and suggestions. Albert Lee.
          Albert Lee made changes -
          Attachment OPENJPA-957.patch [ 12404620 ]
          Albert Lee made changes -
          Attachment OPENJPA-957.patch [ 12404620 ]
          Albert Lee made changes -
          Attachment OPENJPA-957.patch [ 12404623 ]
          Albert Lee committed 762161 (41 files)
          Reviews: none

          OPENJPA-957 - Create Fetch*HintHandler(s) for property processing in EntityManager/Query interface methods.

          openjpa trunk
          Albert Lee committed 762177 (1 file)
          Reviews: none

          OPENJPA-957 - Guard NPE as fetch may be null in getForUpdateClause.

          Albert Lee made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Fix Version/s 2.0.0 [ 12313483 ]
          Resolution Fixed [ 1 ]
          Donald Woods made changes -
          Status Resolved [ 5 ] Closed [ 6 ]

            People

            • Assignee:
              Albert Lee
              Reporter:
              Jeremy Bauer
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:

                Development