SessionSynchronization with Seam managed tx & pc

[gjeudy]

Hi,

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:

Component.getInstance("entityManager")

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).

components.xml

<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.

Thanks,
-Guillaume

[gjeudy]

Sorry for the duplicated posts, the app server crashed on me when a message telling me to email christian bauer :-). Looks like the post was still stored.

I have made more tests on my issue. It looks like I am right, Seam leverages Jboss ServerVMClientUserTransaction to control transaction boundaries in JBoss EJB3 container which means I cannot really trust SessionSynchronization callback from EJB3 container which doesn't reflect the Seam transactional boundaries.

I also noticed that EjbSynchronizations and SynchronizationRegistry together raise Seam events: org.jboss.seam.afterTransactionCompletion and org.jboss.seam.beforeTransactionCompletion. It would be so nice if Seam could also raise a org.jboss.seam.afterTransactionBegin event! That would make my day.

I am still stuck with my problem as of now. I might consider disabling seam transaction but is this even something recommended ? I expect the number of transactions created during a single request cycle to skyrocket! This means I would need a Session facade EJB to route the requests in order to reduce the number of transactions defeating the Seam programming model...

Any inputs appreciated..
Thanks,
-Guillaume