i use Hibernate 3 with CMT[container managed transaction] on jboss 4.

- if session flushmode is set to FlushMode.COMMIT, then it appears more efficient and there are much less concurrency related exceptions than the default FlushMode.AUTO.
But are there consequences of not using FlushMode.AUTO with CMT? can data be corrupted?

- lost update problem happens with isolation level READ_COMMITTED. Hibernate uses optimistic versioning which should solve the problem. But what about the lost update problem on the version number itself? Transaction 1 reads version number, then transaction B reads version number and updates the row data and version number, so now transaction 1 has wrong version number but it still commits anyway? Does Hibernate get a row read lock[other transactions cannot update] when it reads the version number? If yes, then it appears no advantage of using READ_COMMITTED because read lock is equivalent to isolation level REPEATABLE_READ?

- The problem "AbstractFlushingEventListener Could not synchronize database .." happens very often. It is apparently a concurrency related problem. What is the cause and how to avoid this?

I'll just try to answer the second question. From what I understand, the second transaction will not be able to execute the update, because, with managed versioning, the update clause includes a where condition - WHERE version = <version read by the transaction>. If the version was incremented by another transaction in the meantime, the where will not be matched, and the second update will not succeed. This will return 0 as the number of updated rows, which will cause Hibernate to throw a stale data exception.