UI independent conversation and Seam managed persistence con

[t.skultinas]

Hi all,
currently I evaluating Seam for use in several our projects and have question about conversation and Seam managed persitence context. I'm trying to create reusable DAO components with statefull persistence. Since these DAOs are reusable the entity manager scope depends on logic in Business components too. One of solution was to inject Seam managed extended persistence context which scope is Conversation. But the problem comes when some isolated from current conversation CRUD or search operations should be performed in Business component. Does Seam support creation of isolated, nested business layer (UI independent) conversations? In my tests annotations @Begin(nested=?true?) and @End does not help and always the same Seam managed entity manager instance is injected to DAOs. Entity manger component is created, destroyed and etc only after UI events like ?afterPahese()?. Have I missed some Seam functionality or Application managed extended persistence contexts should be used in this case?

Thanks

[gavin.king]

If you have these kinds of complex requirements it is probably better to use EJB container-managed persistence contexts.

The basic pattern is to have an SFSB driving the conversation, that owns an extended PC. If you call methods of SLSB DAOs in the same txn, the extended PC will propoagate. If you don't want the PC to propagate, call a REQUIRES_NEW method.

Make sense?

[t.skultinas]

If you have these kinds of complex requirements it is probably better to use EJB container-managed persistence contexts.

The basic pattern is to have an SFSB driving the conversation, that owns an extended PC. If you call methods of SLSB DAOs in the same txn, the extended PC will propoagate. If you don't want the PC to propagate, call a REQUIRES_NEW method.

Make sense?

I have missed the point how SFSB Business component owning EM can control SLSB DAO which also contains EM. Or this EM from Business SFSB should be passed to DAO SLSB?

If I have SLSB DAO with not extended persitence context, I can control EM using EJB3 declarative transactions (requires, requires_new) from business logic SB. But there is the problem of LazyInitializationException.

If I use SFSB DAO with container managed extended persistence context than I have 2 disadvantages comparing to Seam managed extended persistence context or application managed extended persitence context:
1) Different EM instances will be injected to different DAOs what is not good if cascades in entities are not used (some design solution can be found for this problem)
2) EM cache cleanup strategy because EM scope is session and not conversation or request.

If I understand correctly container managed extended persistence context only joins active JTA but you can't control EM using transaction demarcation. e.x. perform search operation which results are not effected by changed done to entities and etc.

I'm looking for some extended persistence context which scope is less than session (like conversation) managing mechanism with transaction and EM isolation support. It will be useful to reuse some container managed or Seam managed mechanism instead of implementing own application managed.

[gavin.king]

"t.skultinas" wrote:
I have missed the point how SFSB Business component owning EM can control SLSB DAO which also contains EM. Or this EM from Business SFSB should be passed to DAO SLSB?

The PC is propagated with the transaction context. As long as you hit the SFSB first, and pick up the extended PC there, you will get the same PC in the SLSB.

"t.skultinas" wrote:
1) Different EM instances will be injected to different DAOs what is not good if cascades in entities are not used (some design solution can be found for this problem)

Not correct. Not as long as you propagate the TX.

"t.skultinas" wrote:
2) EM cache cleanup strategy because EM scope is session and not conversation or request.

Also not correct. If the SFSB is conversation scope, then its extended PC will be conversation scope.

"t.skultinas" wrote:
I'm looking for some extended persistence context which scope is less than session (like conversation) managing mechanism with transaction and EM isolation support.

Right. An SFSB extended PC is exactly that.

[t.skultinas]

Gavin, thanks for advice, I'll test the PC is propagation with the transaction context.

[gavin.king]

Check the EJB spec for the rules.

[t.skultinas]

Check the EJB spec for the rules.

Gavin, your suggested persistence context propagation pattern is a little bit complex in my case. ex. I have business components as SB that should not be depended on Persistence API and DAO components which hides Persistence API as SLSB. To control persistence context propagation I have to call DAO from Business component through some third SFSB that owns extended persitence context. Is there any other solution that allows to control persistence context propagation or switch EM in DAO without SFSB in the middle between Business component and DAO?

[t.skultinas]

Any ideas except application managed entity managers?

[gavin.king]

Well, you knocked my idea on the head, in my view prematurely :-)