[
https://issues.apache.org/jira/browse/OPENJPA-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12756693#action_12756693 ]
Albert Lee commented on OPENJPA-1306:
-------------------------------------
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
