Hello Alex, anonymous wrote : | No updates will be ever lost with higher isolation levels. The database will ensure that no two transactions that update the same data item can proceed. | Yes, I agree. But the db will block the second update until transaction with first update commits. There is no need to use optimistic locking with repeatable read isolation level because optimistic locking does not work with repeatable read. If I understand it well, we have optimistic locking to prevent conflicting updates. We do not want to send two conflicting updates to db because db (in my case Oracle) will block the second update. We want application could see that another committed tx changed our row (that we already read) and we want to rollback our tx immediately (without blocking). If we set transaction to repeatable read isolation level, in my opinion optimistic locking does not work, because during whole transaction we always read same version of our row. The application can not see that another commited tx updated some row. (bacause we have repeatable read). I think that optimistic locking needs non-repeatable read to work but jbpm docs says opposite. Regards Pavel View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159410#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...