hi

i'm using the Hibernate EntityManager for database access in a multi-threaded application.

while browsing the Pro EJB 3: Java Persistenced API book i found the following pieces of information on JPA & concurrency:

1. a managed entity should not be managed by more than one persistence context at any given time (p. 279)
2. persistence contexts are not intended to be accessed by more than one concurrently executing thread. The application cannot expect it to
be synchronized and is responsible for ensuring that it stays within the thread that obtained it. (p. 279)

does this also apply to Hibernate EntityManager?

does the last sentence in statement 2 mean that an EntityManager cannot be used from threads other than the one that created the manager even if access to the manager is serialized?

what kinds of patters are typically used for handling concurrent access to managed entities and EntityManager?

Optimistic locking - @Version annotation.



Where do you want to use the same EM in different threads?

My application accesses managed entities from multiple threads. There's a sort of pipeline through which managed objects are passed. Worker threads in the pipeline are responsible for taking incoming objects in certain statuses, processing them and passing them on to the next worker (by updating the item statuses).

Should every thread have their own EntityManagers? How would i ensure an entity is not managed by more than one EntityManager at a given time in this case?

Some data related to managed entities is stored in the file system so before processing file system data the thread needs to ensure exclusive access to the entity. These modifications can't be undone right now, so the thread can't roll back the changes if there's an OptimisticLockException.

The thing with one EM per multiple threads is that it may take a long transaction, which you probably don't want.
Or you can write somesort of conversation with that EM - take a look at Seam if it can help you there - not using the web part, just conversation + business process part.
Or do a EM per thread with really short transactions + recoverable optimistic locking.