Optimistic Locking

[sheckler]

I would like to use optimistic locking strategy with jboss 3.2.1.

With Xdoclet tag
@ejb:bean use-soft-locking="true"
a version attribute is generated and incremented with every ejbStore call. On saving a record the value of version is compared to the value of version in the database. If there is a difference, an IllegalStateException is thrown.
As ejbStore is called even with every getter despite of the commit-option (A,B,C) the value of version is allways different and therefore an exception is allways thrown.
ejbSore should only be called, when data has been modified. How can this be achieved configuring jboss (3.2.1)?
I have full documentation, but did not find a solution there.

Thanks for helping
Stefan

[rakhbari]

> I would like to use optimistic locking strategy with
> jboss 3.2.1.
>
> With Xdoclet tag
> @ejb:bean use-soft-locking="true"
> a version attribute is generated and incremented with
> every ejbStore call. On saving a record the value of
> version is compared to the value of version in the
> database. If there is a difference, an
> IllegalStateException is thrown.
> As ejbStore is called even with every getter despite
> of the commit-option (A,B,C) the value of version is
> allways different and therefore an exception is
> allways thrown.
> ejbSore should only be called, when data has been
> modified. How can this be achieved configuring jboss
> (3.2.1)?
> I have full documentation, but did not find a
> solution there.
>
> Thanks for helping
> Stefan

Stefan,

This has absolutely nothing to do with JBoss, other than the fact that JBoss (per the EJB spec) calls ejbStore() at the end of every remote or local interface method that's called on the bean, whether or not data in the bean was actually changed.

I'd read in some forum messages that if you include a isModified() method in your entity implementation JBoss would call it BEFORE IT CALLED ejbStore(), but it's not even doing that.

In any case, it's really the combination of the Xdoclet "use-soft-locking" feature, and JBoss' ignorance of isModified() is what's faulty.

I had to break down and modify Xdoclet's entitycmp.xdt and entity-body.xdt code generation templates to get them to produce the correct code.

Once I'd done that, everything works great now. Xdocet now generates the xxxxxxCMP.ejbStore() method to call my isModified() right at the beginning and if it returns false, it returns immediately so the setVersion() call never happens and the record in the table is untouched. Of course I had to muck with the template's implementation of the setXXXXXXValue() method as well so that it would set my modified flag to true so that the call to ejbStore() would store the dirty bean.

This took many hours of researching, reading forums, learning Xdoclet template language, etc. Too much freakin work if you ask me, but now that it's done, I can create entity beans via Xdoclet till the end of time and they all behave as above.

-RA

[rshahinian]

RA,

First.

The following statement at the beginning of your response seems to be false:
"JBoss (per the EJB spec) calls ejbStore() at the end of every remote or local interface method that's called on the bean, whether or not data in the bean was actually changed."

Actually ejbStore() is called during transaction commit sequence (see 10.9.4 of EJB 2.0 specification.

Therefore it makes more sense to put transaction-attribute of getters as "Supported".
The transaction-attribute of setters must be defined completely functionally to avoid lost updates of single field if it is the only operation invoked on local or remote interfaces (not by a session been operation) business process. In this case it needs to be set as "Required".

And second.

The implementation of optimistic locking isn't a responsibility of bean containers but could be implemented using value objects, versioning, and pessimistic locking mechanism. There will be no essential performance penalties acting so.

This things will work wit all (A, B, C) options of commit.

I will be glad to get some response.

Razmik