Identify correct and incorrect statements about concurrency, including how it is managed through the use of @Version attributes and optimistic locking.

[Note]

Optimistic locking is a technique that is used to insure that updates to the database data corresponding to the state of an entity are made only when NO intervening transaction has updated that data for the entity state since the entity state was read. This insures that updates or deletes to that data are consistent with the current state of the database and that intervening updates are NOT LOST. Transactions that would cause this constraint to be violated result in an OptimisticLockException being thrown and transaction ROLLBACK.

Portable applications that wish to enable optimistic locking for entities must specify @Version attributes for those entities - i.e., persistent properties or fields annotated with the @Version annotation or specified in the XML descriptor as version attributes. Applications are strongly encouraged to enable optimistic locking for all entities that may be concurrently accessed or merged from a disconnected state. Failure to use optimistic locking may lead to inconsistent entity state, lost updates and other state irregularities. If optimistic locking is not defined as part of the entity state, the application must bear the burden of maintaining data consistency.

Version Attributes

The @Version field or property is used by the persistence provider to perform optimistic locking. It is accessed and/or set by the persistence provider in the course of performing lifecycle operations on the entity instance. An entity is automatically enabled for optimistic locking if it has a property or field mapped with a @Version mapping.

An entity may access the state of its version field or property or export a method for use by the application to access the version, but MUST NOT modify the version value. Only the persistence provider is permitted to set or update the value of the version attribute in the object.

The version attribute is updated by the persistence provider runtime when the object is WRITTEN to the database. All non-relationship fields and properties and all relationships owned by the entity are included in version checks.

The persistence provider's implementation of the merge operation MUST examine the version attribute when an entity is being merged and throw an OptimisticLockException if it is discovered that the object being merged is a stale copy of the entity - i.e. that the entity has been updated since the entity became detached. Depending on the implementation strategy used, it is possible that this exception may not be thrown until flush is called or commit time, whichever happens first.

The persistence provider runtime is only required to use the version attribute when performing optimistic lock checking. Persistence provider implementations may provide additional mechanisms beside version attributes to enable optimistic lock checking. However, support for such mechanisms is not required of an implementation of EJB 3.0 specification.

If only some entities contain version attributes, the persistence provider runtime is required to check those entities for which version attributes have been specified. The consistency of the object graph is not guaranteed, but the absence of version attributes on some of the entities will not stop operations from completing.

Example:

@Entity
public class Article {

    @Id private long id;
    
    @Column(name="VERS")
    @Version
    private int ver;

	...
}
					

The same metadata expressed in XML:


<entity-mappings>
	<entity class="Article">
		<attributes>
			<id name="id"/>			
			<version name="ver">
				<column name="VERS"/>
			</version>
			...
		</attributes>
	</entity>
</entity-mappings>

					

OptimisticLockException

Provider implementations may defer writing to the database until the end of the transaction, when consistent with the flush mode setting in effect. In this case, the optimistic lock check may not occur until commit time, and the OptimisticLockException may be thrown in the "before completion" phase of the commit. If the OptimisticLockException must be caught or handled by the application, the flush method should be used by the application to force the database writes to occur. This will allow the application to catch and handle optimistic lock exceptions.

The OptimisticLockException provides an API to return the object that caused the exception to be thrown. The object reference is not guaranteed to be present every time the exception is thrown but should be provided whenever the persistence provider can supply it. Applications cannot rely upon this object being available.

In some cases an OptimisticLockException will be thrown and wrapped by another exception, such as a RemoteException, when VM boundaries are crossed. Entities that may be referenced in wrapped exceptions should be Serializable so that marshalling will not fail.

An OptimisticLockException ALWAYS causes the transaction to ROLL BACK.

Refreshing objects or reloading objects in a new transaction context and then retrying the transaction is a potential response to an OptimisticLockException.

Professional hosting     Belorussian informational portal         Free SCWCD 1.4 Study Guide     Free SCDJWS 1.4 Study Guide     SCDJWS 1.4 Quiz     Free IBM Certified Associate Developer Study Guide     IBM Test 000-287. Enterprise Application Development with IBM WebSphere Studio, V5.0 Study Guide     Free Mock Exam Engine