DJ> Just to make sure I understand: I think this relies on the database DJ> transaction isolation level to be read committed or weaker?
Yes, currently, to be consistent, the tx level should be read committed. I am thinking about the case of read uncommitted. Suppose, one tx modified entity. Another tx wants load more fields while it locked some already. Then, I could check whether the locked fields are changed. If they are, then the exception is thrown that there is no such entity anymore. What do you think about it? DJ> with repeatable read, snapshot (not a jdbc "official" level) or serializable, DJ> the update should fail due to the databases consistency strategy rather DJ> than checking rows changed in the update since the only value visible to DJ> the update in tx1 is its original version number. Is this correct? The lock and CMP engine is unaware of tx isolation level, so their behaviour is the same. On tx commit SQL UPDATE is perfomed. And if the locked column[s] are changed then UPDATE will fail. The only difference between read committed and stricter levels I see is that transactions will be serialized by the db but the cause of the failure will be the same, as I imagine it. Do you agree? DJ> thanks again Thank you alex DJ> david jencks ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
