2 Replies Latest reply on Mar 14, 2005 6:19 AM by Alexey Loubyansky

    Optimistic locking strategies with CMR fields

    Albert Aymerich Newbie

      Hi all...

      We are using JBoss 3.2.6, SapDb as database, CMP and CMR capabilities of JBoss, and for some reporting features (for performance) a DAO pattern (acces direct to database with JDBC).

      We are testing some configuration options of the locking strategies proposed by Jboss docs, because with the default configuration of container (Standard CMP2 entity Bean- pessimistic locking, commit option B, some methods of EJBs marked as read-only) we have deadlocks and performance problems.

      We have tested the optimistic locking (IPT- commit option C, and read-strategy). Read strategy takes in account read/modified fields of beans when doing the update to the database (from JBoss docs) ...my question is:

      Why modified fileds are taking in account? with this behaviour, the where clause of the update sentence have the modified values... and not the original values readed from database. So, the update never find any row because is doing the update with the modified values, and not the original... so the transaction is always rollbacked.
      To avoid this, we must disable the locking strategies...but then, we will have lost updates.

      Also, we think that the optimistic locking strategies (at least modified and read) doesn't work with CMR fields...we have put traces n the LockingStrategy class for the read strategy.. and never use it.

      We see that, with the CMR relation, our application is getting (read) only two values from the entity (two diferent selects to database), and the update contains only the updated values (in the set clause and the wehre clause) and not the getted values (as read-strategy propose).

      Can anybody confirm this? Or.. Can anybody tell me some clues where to see and modify-correct this behaviour (at least for my application)??

      Thanks in advance...

      PD: sorry for my poor english and for the long post