Spring and Seam managed persistence contexts

[hubaghdadi]

Hi.
If my application use Spring for middleware logic (DAO, transaction management and facades), could I leverage it to use Seam managed persistence context?
Or Spring kills those managed context?
Thanks.

[youngm]

Yes. you can use Spring as your middleware and take full advantage of Seam managed persistence contexts without seam or Spring being non the wiser. The documentation details how you can use Seam Managed persistence contexts with spring and how you can use Spring managed transactions with Seam:

http://docs.jboss.com/seam/2.0.0.CR2/reference/en/html/spring.html

Mike

[rhasselbaum]

Is it possible to have a conversation-scoped persistence context (or Hibernate session) inside a Spring-based "stateless" DAO, which is not a Seam component?

[youngm]

Yup through:

*Template
SharedEntityManager
@PersistenceContext
SessionFactory.currentSession()

You can make your existing spring persistence code work with a conversation scoped persistence context without changing your code. Simply configure the use of a different EntitityManagerFactory of SessionFactory

Mike

[rhasselbaum]

Hmm... pretty cool. How does the factory know what session to use? Must be storing some contextual state in thread-local storage?

[youngm]

The integration uses a dummy SessionFactory that simply takes calls to SessionFactory.createSession and returns the Seam managed session instead. It's quite simple. So you just need to make sure that you use the SeamManagedSessionFactory in the correct places instead of the real SessionFactory.

Mike

[rhasselbaum]

Right, but I'm just wondering how (internally) the Seam-managed factory knows which session to return, given the fact that the object holding the factory (i.e. the DAO) is shared among all threads/conversations. Does the conversation state get put into thread-local storage and the Seam-managed session factory looks it up from there?

I guess I could just look at the code. ;-)

[youngm]

Oh, ya. Seam uses a thread local to get it's "Context" and then uses the various scopes in that context to determine the actual values in the scopes. If you wanna get into much more detail on how Seam manages it's scopes it would probably be best to look at the code. I think the key here is that this integration lets Seam do it's thing and Spring do it's thing and the actual connection between the 2 is quite loose. So if you wanna use a Seam managed persistence context you just need to make sure Seam is set up correctly for the Context of that call into the spring singleton and it will just work.

The spring seam integration also contains code to attempt to automatically set up a Seam Context and scopes it in a spring transaction in the case of a non web request originated call into spring.

[rhasselbaum]

Good stuff. Thanks.