openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Albert Lee (JIRA)" <>
Subject [jira] Commented: (OPENJPA-1306) Extended lock scope support
Date Thu, 17 Sep 2009 18:50:57 GMT


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. 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:
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 {
		private E11 owned;
	@Entity Class E11 {
		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.

> Extended lock scope support
> ---------------------------
>                 Key: OPENJPA-1306
>                 URL:
>             Project: OpenJPA
>          Issue Type: Sub-task
>            Reporter: Albert Lee
>            Assignee: Albert Lee

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message