I have implemented a new AOP service for Serializable POJOs, Versioned
Objects.  You can transactionally version an object.  If you modify the
object within a transaction, this modification is not seen by other
transactions.  If the tx commits, the changes seen, if a rollback happens
the changes are rolled back.  On commit, if another tx has modified the
object, the tx will rollback (OptimisticLocking).

The way it works is as follows:

POJO pojo = new POJO();
pojo = (POJO)org.jboss.aop.plugins.Versioned.makeVersioned(pojo);

calling Versioned.makeVersioned creates a proxy that sits in front of the
real object.



when callMethod is invoked since there is a transaction, an interceptor
creates a copy of the REAL pojo and does all further invocations on this

pojo.someField = 5;

If you have field interception turned on, public field will also be accessed
via the copy/version


On commit, a tx Synchronization checks to see if the version you have
created is the latest and greatest.  If not an
org.jboss.aop.plugins.OptimisticLockFailure exception is thrown in
beforeCompletion.  I'm not sure how this exception is wrapped.

Some other semantics:

1. All method invocations force a version to be created.  You can avoid this
by declared class-metadata as follows:

<class-metadata name="234234" group="VERSIONED"
<method name="get.*">

A readonly method will not cause the creation of a version and the current
object will be used.

An example and unit test is under

The example object VersionedPOJO.java, has 1 interceptor pointcut declared
on the class to do Tx stuff.  See
testsuite/src/resources/aop/META-INF/jboss-aop.xml for more details.

What would be nice is to also write a TransactionalLock interceptor for
versioned POJO's that have high OptimisticLock failures.


This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
Jboss-development mailing list

Reply via email to