Details

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

      Activity

      Albert Lee created issue -
      Hide
      Albert Lee added a comment -

      Implement new JPA 2.0 pessimistic lock extended scope support per section 3.4.3.

      Show
      Albert Lee added a comment - Implement new JPA 2.0 pessimistic lock extended scope support per section 3.4.3.
      Albert Lee made changes -
      Field Original Value New Value
      Status Open [ 1 ] In Progress [ 3 ]
      Hide
      Albert Lee added a comment -

      Per spec:
      ______________________________________
      3.4.3 Pessimistic Lock

      Element collections and relationships owned by the entity that are contained in join tables will be locked if the javax.persistence.lock.scope property is specified with a value of PessimisticLockScope.EXTENDED. This property may be passed as an argument to the methods of the EntityManager and Query interfaces that allow lock modes to be specified or used with the NamedQuery annotation.

      3.4.4.3 Lock Mode Properties and Uses
      The following property is defined by this specification for use in pessimistic locking, as described in section 3.4.3:
      javax.persistence.lock.scope
      This property may be used with the methods of the EntityManager interface that allow lock modes to be specified, the Query.setLockMode method and the NamedQuery annotation. When specified, this property must be observed.
      ______________________________________
      We encountered the following ambiguities:

      1. The above wording should be more consistent, i.e. either use "Query interface that allow lock modes to be specified" or "Query.setLockModde method". The former wording is preferred.

      2. Given the Query interface has only the setLockMode() method that takes LockModeType as a parameter, it does not have a setLockMode that takes a property map (e.g. setLockMode(LockModeType, Properties)) like all the other EntityManager interface methods. Therefore there is no mean to specify the "javax.persistence.lock.scope" property on the "setLockMode method" or "any method that allow lock modes to be specified". The alternative is to use setHint() method but the contract implies the hint MAY NOT be observed:

      • Set a query hint. If a vendor-specific hint is not recognized,
      • it is silently ignored. Portable applications should not
      • rely on the standard timeout hint. Depending on the database
      • in use and the locking mechanisms used by the provider, the
      • hint may or may not be observed.

      The spec needs to spell out how the property can be specified in the Query interface.

      3. When extended lock scope is specified, the spec lays out the associated relationship/element collection entity will be locked when lock applies to an entity. However it does not specify if the extended locking scheme will be cascaded to the relationship/collection. I hope this is NOT the intent, otherwise it will be another piece of work similar to the cascade detach which will be more complex than expected.

      4. What should be returned on the EntityManager interface getLockMode() method when lock scope is NORMAL(default) or EXTENDED? For example,
      @Entity Class E1

      { @OneToOne private E11 owned; }

      @Entity Class E11

      { @OneToOne(MappedBy=owned) private E1 owner; }

      Map<String,Object> props1 = new HashMap<String,Object>();
      props.put("javax.persistence.lock.scope", PessimisticLockScope.NORMAL); // default
      E1 e1 = em.find(E1.class, id, LockModeType.PESSIMISTIC_WRITE);
      assertEqual( em.getLockMode(e1), LockModeType.PESSIMISTIC_WRITE);
      assertEqual( em.getLockMode(e1.getOwned()), LockModeType.NONE); <<<< Is this what is expected

      Map<String,Object> props2 = new HashMap<String,Object>();
      props.put("javax.persistence.lock.scope", PessimisticLockScope.EXTENDED);
      E1 e2 = em.find(E1.class, id, LockModeType.PESSIMISTIC_WRITE, props2);
      assertEqual( em.getLockMode(e2), LockModeType.PESSIMISTIC_WRITE);
      assertEqual( em.getLockMode(e2.getOwned()), LockModeType.PESSIMISTIC_WRITE); <<<< Is this what is expected

      Albert Lee.

      Show
      Albert Lee added a comment - Per spec: ______________________________________ 3.4.3 Pessimistic Lock Element collections and relationships owned by the entity that are contained in join tables will be locked if the javax.persistence.lock.scope property is specified with a value of PessimisticLockScope.EXTENDED. This property may be passed as an argument to the methods of the EntityManager and Query interfaces that allow lock modes to be specified or used with the NamedQuery annotation. 3.4.4.3 Lock Mode Properties and Uses The following property is defined by this specification for use in pessimistic locking, as described in section 3.4.3: javax.persistence.lock.scope This property may be used with the methods of the EntityManager interface that allow lock modes to be specified, the Query.setLockMode method and the NamedQuery annotation. When specified, this property must be observed. ______________________________________ We encountered the following ambiguities: 1. The above wording should be more consistent, i.e. either use "Query interface that allow lock modes to be specified" or "Query.setLockModde method". The former wording is preferred. 2. Given the Query interface has only the setLockMode() method that takes LockModeType as a parameter, it does not have a setLockMode that takes a property map (e.g. setLockMode(LockModeType, Properties)) like all the other EntityManager interface methods. Therefore there is no mean to specify the "javax.persistence.lock.scope" property on the "setLockMode method" or "any method that allow lock modes to be specified". The alternative is to use setHint() method but the contract implies the hint MAY NOT be observed: Set a query hint. If a vendor-specific hint is not recognized, it is silently ignored. Portable applications should not rely on the standard timeout hint. Depending on the database in use and the locking mechanisms used by the provider, the hint may or may not be observed. The spec needs to spell out how the property can be specified in the Query interface. 3. When extended lock scope is specified, the spec lays out the associated relationship/element collection entity will be locked when lock applies to an entity. However it does not specify if the extended locking scheme will be cascaded to the relationship/collection. I hope this is NOT the intent, otherwise it will be another piece of work similar to the cascade detach which will be more complex than expected. 4. What should be returned on the EntityManager interface getLockMode() method when lock scope is NORMAL(default) or EXTENDED? For example, @Entity Class E1 { @OneToOne private E11 owned; } @Entity Class E11 { @OneToOne(MappedBy=owned) private E1 owner; } Map<String,Object> props1 = new HashMap<String,Object>(); props.put("javax.persistence.lock.scope", PessimisticLockScope.NORMAL); // default E1 e1 = em.find(E1.class, id, LockModeType.PESSIMISTIC_WRITE); assertEqual( em.getLockMode(e1), LockModeType.PESSIMISTIC_WRITE); assertEqual( em.getLockMode(e1.getOwned()), LockModeType.NONE); <<<< Is this what is expected Map<String,Object> props2 = new HashMap<String,Object>(); props.put("javax.persistence.lock.scope", PessimisticLockScope.EXTENDED); E1 e2 = em.find(E1.class, id, LockModeType.PESSIMISTIC_WRITE, props2); assertEqual( em.getLockMode(e2), LockModeType.PESSIMISTIC_WRITE); assertEqual( em.getLockMode(e2.getOwned()), LockModeType.PESSIMISTIC_WRITE); <<<< Is this what is expected Albert Lee.
      Jeremy Bauer made changes -
      Hide
      Albert Lee added a comment -

      Outstanding issues resolved and clarified in the current level of the spec.

      The current mixed lock manager is a super set implementation of the required extended lock scope semantics, meaning requested pessimistic mode locks more than required by the extended lock scope definition. There are a few usage cases require additional locking to the join table in order to meet the extended lock scope requirement. In other use cases, optimization can be performed to minimize "un-needed" locks on relationship and collection elements to improve concurrency. The later case is not required in order to be spec compliance but can be considered as improvement in the future. All these additional semantics will only be applied iff mixed lock manager (JPA2) is used and extended lock scope is specified.

      Show
      Albert Lee added a comment - Outstanding issues resolved and clarified in the current level of the spec. The current mixed lock manager is a super set implementation of the required extended lock scope semantics, meaning requested pessimistic mode locks more than required by the extended lock scope definition. There are a few usage cases require additional locking to the join table in order to meet the extended lock scope requirement. In other use cases, optimization can be performed to minimize "un-needed" locks on relationship and collection elements to improve concurrency. The later case is not required in order to be spec compliance but can be considered as improvement in the future. All these additional semantics will only be applied iff mixed lock manager (JPA2) is used and extended lock scope is specified.
      Albert Lee made changes -
      Status In Progress [ 3 ] Resolved [ 5 ]
      Fix Version/s 2.0.0 [ 12314019 ]
      Resolution Fixed [ 1 ]
      Donald Woods made changes -
      Fix Version/s 2.0.0-beta [ 12314149 ]
      Fix Version/s 2.0.0 [ 12314019 ]
      Affects Version/s 2.0.0-M3 [ 12314148 ]
      Donald Woods made changes -
      Status Resolved [ 5 ] Closed [ 6 ]

        People

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

          Dates

          • Created:
            Updated:
            Resolved:

            Development