Hi, all! We noticed an interesting problem with optimistic locking. The problem is frequent versioning exceptions on objects which are very rarely modified or even read-only. If we run a stress test, the errors appear almost immediately, while in real-life use they occur at least a few times a day, which is bad enough. Because of this, we had to temporarily switch JBC off, because we couldn't find a working configuration, but since 1.4.1 SP1 our application seems to run well in pessimistic mode. So this is no longer a critical problem, but I still think it deserves some attention. The thing is that these errors seem really unnecessary. I do not know precisely how the combination of Hibernate + JBoss Cache works, but the nature of our application is such that real concurrent modifications of the same objects are extremely rare (it is basically a BPM application, using JBPM 3.0, where objects or records are mainly just inserted, and modifications are mostly done in a "private" context, where each user/process/thread only touches its own objects). So where do these errors come from? I'm pretty sure the objects causing errors are NOT being modified, much less concurrently - they are merely being concurrently accessed, but that should not be a problem, right? I also have a question as to which locking mode is better to use in an application such as ours, where the possibility of concurrent object modifications is almost none. Of course we will stay with pessimistic for now, because it works. I'm just wondering if this is the optimal choice anyway, or are we missing something? Regards, Jaka View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4014746#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...