I have been using Seam managed transactions and persistence contexts with success so far until I tried to modify one of my SFSB seam bean to implement EJB3 SessionSynchronization callback interface.
I used to implement cross-cutting logic in EJB3 interceptors, the problem is that logic gets called everytime the method with the interceptor gets called, which can be many times if the interceptor is bound to many methods of loosely coupled session seam beans. This cross-cutting logic is really bound to the lifecycle of a transaction, therefore to optimize this process I thought I would move the logic inside my interceptor to:
afterBegin() callback on the SessionSynchronization interface.
I had to use:
inside afterBegin() since @In injection is not completed by the time the callback method is called.
Lo and behold the afterBegin() callback gets called after every call to every business methods on my SFSB (from the web tier). I noticed that the callback wouldn't be called on a SLSB if the SFSB method calls an SLSB method in turn. This last bit is reassuring since it proves to me that the transaction is getting propagated.
Does Seam support any transaction lifecycle callback specific to Seam managed transactions? If not, is SessionSynchronization usage recommended with Seam managed transactions and persistence context?
Is there something I've done wrong in my setup? I thought Seam managed transactions guaranteed 2 and only 2 transactions created per request cycle ? See: here . Yet through my tests I confirm afterBegin() is called as many times as business methods are called on my outer EJB (the one serving Seam client request directly).
<persistence:managed-persistence-context name="entityManager" auto-create="true" persistence-unit-jndi-name="java:/rdmEntityManagerFactory" /> <transaction:ejb-transaction />
PS: I need Seam experts to clarify, I have my own theory to explain this behavior, the afterBegin() callback cannot be called at the right time because it is called by the EJB3 container which is unaware of Seam (does it mean EJB3 container thinks it is starting a transaction when in fact it is not ?). Seam is just another client of the EJB3 container and therefore the container would call afterBegin() callback everytime Seam calls a business method. I'm not sure how Seam pulls off the transaction management part however. How is it possible for Seam to tell the container to begin a transaction and then execute numerous business methods in the scope of that same transaction ?
Any pointers appreciated, I'm pretty much in the dark here.