You are reading the Sun One docs, yes? I haven't used their implementation, but have used something similar, and mucked around with timestamp-based optimistic locks. So far my reaction is:
Run away. Far away. Save your life while you can.
This stuff can get confusing, and I haven't had much luck getting performance differences in a real app that warranted the complication. There might be highly-loaded transactional systems that need this but I haven't hit a situation yet that wasn't better served by first figuring out if there wasn't something more fundamentally wrong with how processing was being performed.
One big caveat to that is I haven't pounded hugely on clustered situations, and I can imagine that could change the situation.
To answer your original question more concretely, muck around with options for logging the actual SQL activity in the CMP layer. I think you'll undertand much more clearly what is going on at that point. Even doing that without version consistency would be informative. Containers do a lot more probing into the database than you might expect, and the Sun One explanations will make more sense to you after you've seen those probes. Also, if you experiment with vendor-specific options for tuning how the CMP layer works and see the consequent alterations in that probing, you'll also get a better sense of why you'll often not care about version consistency as a potential solution. I think you'll find that you end up trading row locks for read probes, so I think you'll only win with VC if lock contention truly has become your bottleneck. [ February 15, 2006: Message edited by: Reid M. Pinchback ]