Optimistic Transactions Spanning Web Requests

[mwax]

I need to create an optimistic lock across multiple web requests, for example, while a user fills out a multipage form. I can do this easily in BMP and in EJB 1.1 CMP beans because I write my own set methods (and can control a version number) in these.

How can I do this in EJB 2.0 CMP beans?

[juha]

There's optimistic locking support in jbosscmp-jdbc.xml

[mwax]

We are trying to use this. However, we find that when we return an optimistic version number from the client and use it to set the corresponding entity field, there is no optimistic locking. We can make optimistic locking span multiple requests by checking the optimistic version number ourselves.

Is the optimistic locking based on the version number pulled from the database at the start of the transaction? That would explain our results: setting the optimistic attribute with a value returned from the client would then not cause optimistic lock violation, as the attribute pulled from the database would be the one actually checked.

Actually, we were hoping for something closer to the request-spanning optimistic locking provided by WebLogic.

[juha]

There are several strategies available that mostly fit into two categories: you have an explicit column in your database schema (version, timestamp, UID) which is used for checking the version you're attempting to store or the CMP field values of your in-memory instance are compared to values persisted in the database and a commit/rollback decision is made based on that (and there are no explicit optimistic locking columns in the schema).

[mboulatian]

Hi,

We have a big problem using EJB 2.0 with jboss. We use Updatable Value Object Pattern. This means we have individual get and set methods in entity bean's remote interface and also have setData methods to make changes in entity bean's attributes in one remote method call. As you know, this may introduce Stale Value Objects. Before considering using CMP 2.0 we were using CMP 1.1. We had version control attribute that was updated in every set method call of bean class. getData method copied the current value of version control in the Value Object and sent it to the client. When updated Value Object was sent back through setData, the implementation of setData within bean class compared version attribute value with the copy of the bean class and thew appropriate exception if they were not the same.

Using CMP 2.0 we can no longer update version control attribute since all set methods are abstract. We thought we can increment version control within ejbStore but jboss can call it without even any entity bean attribute change. So. we thought we can use optimistic tag and specify version control attribute within jbosscmp-jdbc, but this doesn' t seem to be the case.

I have this questions for Juha:
1) When bean developer specifies version control attribute, does jboss update its value?
2) If it does, then does jboss compare its value in Value Object Pattern scenario and throw any exception? If it does then what is the exception type?
3) If jboss doesn't compare, is there a way that bean developer can compare to let client know of differences?
4) If none of these applies then I would like to hear how this optimistic tag with version-control works so we can try to use jboss with ejb 2.0
5) Is there any other way to do version control check in jboss (weblogic has similar version control and automatically checks and throws exception if versions do not match)

I really appreciate the response.
Thanks,
Misak

[objec]

I too am trying to get optimistic locking that spans web requests. I've read the section in the paydocs and followed the examples, but cannot seam to get the behavior that i want.

I have constructed a sample, if anyone could suggest what i might have wrong. The source can be downloaded here: http://www.sharpuniverse.com/jboss/entitybeanlocking/sample.zip

Here's how it works: All you need to do is modify the build.properties to set your jboss install dir and then run the deploy target. Then go to the "entitybeanlocking" context and you'll see the "current" value.

This jsp page looks the bean up (by static key for testing), puts it in the session and displays the "current value" of a test field. On subsequent requests it uses the bean in the session instead of looking it up. Users can enter a new value on the webpage and submit which is handled by the servlet, which gets the bean out of the session and updates the value.

Here's how to demonstrate the problem: Open the first browser and then the second; you'll see the current value in both. Next update on the original browser, which should work fine. Now, without refreshing, update on the second browser (which had previously displayed an old value) - i'm hoping that this will throw some exception indicating that the value previously displayed was stale, but it doesn't; it updates value without a hitch.

Is it possible to do what i want? If so, does anyone know what i have wrong in my sample?

Just in case you think it's a little odd to put the entitybean in the session - i did this because i'm thinking that the setValue method needs to be called on the same reference.[/url]

[hbjamil]

I have this questions for Juha:
1)When bean developer specifies version control attribute, does jboss update its value?
2) If it does, then does jboss compare its value in Value Object Pattern scenario and throw any exception? If it does then what is the exception type?
3) If jboss doesn't compare, is there a way that bean developer can compare to let client know of differences?
4) If none of these applies then I would like to hear how this optimistic tag with version-control works so we can try to use jboss with ejb 2.0
5) Is there any other way to do version control check in jboss (weblogic has similar version control and automatically checks and throws exception if versions do not match)

Any replies for these question ? They will help others to solve their problem

[aloubyansky]

1) yes
2) no
3) yes, it's a cmp field
5) what does weblogic do here that jboss does not?

To objec's post. This behaviour is expected. Optimistic locking is used to prevent concurrent updates to the data with the same version. When second client invokes a getter, the instance is reloaded from the db with the new version value.

[atait]

Regarding older EJBs using 1.0 deployment descriptors but deployed into 3.2.3 container, can the container manage optimistic locking for these?

Does documentation exist re: the config for Optimistic using the 1.0 EJBs?

Regarding last post, this seems to contradict what is printed in the Admin/dev guide.

Using the "versioning" approach, won't multiple gets() get the same version if the no updates have been made between gets()?

Also, when using the "versioning" approach, does the container detect a conflict and throw an exception when a request to update is associated with an out-of-date version?

[aloubyansky]

Regarding older EJBs using 1.0 deployment descriptors but deployed into 3.2.3 container, can the container manage optimistic locking for these?

No.

Regarding last post, this seems to contradict what is printed in the Admin/dev guide.

What is contradicting?

Using the "versioning" approach, won't multiple gets() get the same version if the no updates have been made between gets()?

Yes, the same value.

Also, when using the "versioning" approach, does the container detect a conflict and throw an exception when a request to update is associated with an out-of-date version?

Sure, that's the purpose of OL. The tx is rolled back.

[atait]

Alexey,

Thanks for your reply. I must have misinterpreted your earlier post. To bad about the 1.0 EJBs but more reason for us to loop back and clean these up.