Hopefully this would help
http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-4902&yr=2007&track=3
Go through the "Concurrency" section of the talk.
glassfish_at_javadesktop.org wrote:
> According to the spec, LockModeType.READ is what I want:
>
> http://java.sun.com/javaee/5/docs/api/javax/persistence/LockModeType.html
>
> Can someone help me better understand what that javadoc is saying? Is it saying that locking an entity won't prevent another transaction from reading the entity and making changes to it, but the lock will cause both transactions to fail because of dirty read or non-repeatable read?
>
> I was hoping that the lock would block other transactions from reading the entity until the transaction has been committed, kind of like a synchronized block in Java code.
>
> I did some googling and saw someone suggesting doing a flush(), then catching OptimisticLockException, then doing a refresh(). When would I do this? Immediately after calling lock(), or immediately after my merge()? If I did it after the merge(), then I'd have to re-do all the work on the entity to set the new values.
>
>
> Thanks,
> Ryan
> [Message sent by forum member 'rdelaplante' (ryan_at_ijws.com)]
>
> http://forums.java.net/jive/thread.jspa?messageID=369017
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>