Announcement Announcement Module
Collapse
No announcement yet.
JPA, PROPAGATION_SUPPORTS and EntityManager bound to the current thread Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • JPA, PROPAGATION_SUPPORTS and EntityManager bound to the current thread

    It is important to have an entityManager bound to the current thread when working with entities having lazy associations. In front-end it can be done using OpenEntityManagerInViewFilter, but how about backend? How to bind an EntityManager to the current thread when the call is invoked from a workflow or jms or some sort of event? What if you have a pool of workers in backend, and each of them, when working on a task, need to have an EntityManager bound to the thread?

    One workaround we have been using is @Transactional(propagation = Propagation.SUPPORTS). When put on a method, it makes the code inside that method share the same EntityManager. However I have noticed that there is a cost to this approach. If entityManager is accessed inside the annotated method, it will create a transaction and bind a synchronization for it. When the method returns, it will call a commit on the jdbc transaction, as part of that synchronization.

    So I have two questions:

    1) Why does @Transactional(propagation = Propagation.SUPPORTS) actually starts a transaction on the first access of EntityManager. The transaction (and the synchronization) is created in ExtendedEntityManagerCreator.enlistInCurrentTransa ction. The method is invoked when EntityManager is accessed, for example when doing a simple find using EntityManage.find. Doing a simple select does not require a transaction, so why does spring start one?

    2) If not @Transactional(propagation = Propagation.SUPPORTS) then what is the best way of binding the EntityManager to the current thread in backend?
Working...
X