Optimistic locking

[senthilcool]

Can optimistic locking be used with "Standard CMP 2.x EntityBean" container and commit option "B" ?

I have written a bean with optimistic locking running in a "Standard CMP 2.x EntityBean" container and commit option "B". But everytime an update is done the container fires two queries. Is this standard behaviour or is there some thing wrong in my configuration.

Code in the stateless session facade is :
IPartyLocalHome partyHome = getPartyLocalHome();
IPartyLocal party = partyHome.findByPrimaryKey(partyId);
party.setName(name);

The log says :
[findByPrimaryKey] Executing SQL: SELECT party_uuid, status_code, name, is_organization_flag, is_person_flag, last_modified_date FROM PARTY WHERE party_uuid=?
[PartyEJB] Executing SQL: SELECT status_code, name, is_organization_flag, is_person_flag, last_modified_date FROM PARTY WHERE (party_uuid=?)
[PartyEJB] Executing SQL: UPDATE PARTY SET name=?, last_modified_date=? WHERE party_uuid=? AND last_modified_date=?
[PartyEJB] Rows affected = 1

I guess the first query is done as a consequence of commit optin B. The second query is done to get the value of the last modified date before the transaction. Is there a way to optimize these into one query.

Thanks for the help.

[senthilcool]

Help !

[ioparra]

A few things:
1)What version of jboss
2)Can I assume all 3 of these calls are in the middle of 1 transaction(ie, your controlling it in the facade or this facade is CMT with a Required or equivalent)?
3)What type of loading are you doing.
Based on the query for the finder, it seems you are doing a on-find loading. But it looks like you may not be having a transaction context propogation from the finder to the setName call. Check to make sure you are setting the transaction to required or control the transaction via UserTransaction. To make sure a different transaction is not started, configure log4j.xml to start listening to org.jboss.tm and look at the begin/end of the transaction. You should only have 1 transaction for the entire thing.

[senthilcool]

Hi Ivan,

Thanks a lot for the reply.

1) I am using jboss-3.2.1_tomcat-4.1.24 downloaded as an executable.
2) All the 3 calls are in the same method of a stateless session bean which has all of its methods configured to container managed transaction of type 'Required' as are the methods in the entity bean.
3) Yes, the read ahead strategy is set to 'on-find'.
Even though I have added the following to my log4j.xml file, I am not able to get the logging of the transactions to work and hence not able to verify that everything is happening in a single transaction.



Pls let me know if there is anything else to be done to turn on the logging.

Thanks again for your time and help.

cheers,
senthil

[ioparra]

There is a JBoss Trace level option.

[senthilcool]

Hi Ivan,

Thanks again. I got the logging to work and found that all the calls in the update method happen in a single transcation. But for some reason the container fires two select queries. Pls take a look at the below method and the attached log file and let me know if you find anything wrong/strange.

public void updatePartyName(String partyId, String name)
throws FinderException {
IPartyLocalHome partyHome = getPartyLocalHome();
IPartyLocal party = partyHome.findByPrimaryKey(partyId);
party.setName(name);
party.setStatus("ACTIVE");
}

cheers,
senthil

[ioparra]

Based on the queries and order, here is the configuration that I see running.
1)Commit Option B
2)Optimistic Locking(timestamp)
3)on-find

Here is the problem, on-find and optimistic locking don't work very well together. Optimistic locking is recorded during the ejbLoad stage, not during the finder method. Because of that, the container does a select to preload its optimistic state, thats why you see the second SQL.

This is an issue I've seen before and can't seem to get around. To save on headaches, you may consider changing from on-find to on-load. That will make the initial finder only return a PK. The rest will look the same.

To remove this problem, change from optimistic to NoLock(or Pessimistic) and you'll see the second query go away(assuming you keep the on-find).

-Ivan

[senthilcool]

Yes, I am using optimistic locking with commit option B and the on-find strategy.

I need to use optimistic locking as I have to prevent concurrent modifications across containers in a cluster. I was hoping that I will be able to reduce the two queries into one as they were happening in the same transaction and thus prevent a trip to the database. But as you explained I guess I will have to live with two queries.
Switching to on-load actually add's the finder with only the PK query to the already existing two queries resulting in 3 queries. I have attached the log file.

I also tried row-locking instead of optimistic locking but even that seems to do the same - query for the finder and then SELECT FOR UPDATE on the ejbLoad.

Ivan, thanks for the help.

cheers,
senthil

[ioparra]

I've tried to reduce the # of sqls done in a clusterable environment, but can't get it lower than 3. The minimum would have to be 2(one finder, one update). I find the clustering very interesting. Because of the nature a "cluster", having Pessimistic locking is invalid. Leaving NoLock or OptimisticLock if you wish the appserver to manager the locking mechanism. NoLock handles that problem(I think) unless you turn on row-locking.

If you haven't already, I'd recommend doing "Instance per Transaction" for your CMPs. That, in combination with OptimisticLocking, should squeeze a little more performace outa your app with out risking to much data integrity.

Good Luck.

-Ivan

[senthilcool]

Thanks.