This content has been marked as final.
Show 8 replies
-
1. Re: UI independent conversation and Seam managed persistence
gavin.king May 24, 2006 10:28 AM (in response to 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? -
2. Re: UI independent conversation and Seam managed persistence
t.skultinas May 24, 2006 11:53 AM (in response to t.skultinas)"gavin.king@jboss.com" wrote:
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. -
3. Re: UI independent conversation and Seam managed persistence
gavin.king May 24, 2006 2:12 PM (in response to t.skultinas)"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. -
4. Re: UI independent conversation and Seam managed persistence
t.skultinas May 24, 2006 2:49 PM (in response to t.skultinas)Gavin, thanks for advice, I'll test the PC is propagation with the transaction context.
-
5. Re: UI independent conversation and Seam managed persistence
gavin.king May 24, 2006 4:15 PM (in response to t.skultinas)Check the EJB spec for the rules.
-
6. Re: UI independent conversation and Seam managed persistence
t.skultinas May 25, 2006 12:31 PM (in response to t.skultinas)"gavin.king@jboss.com" wrote:
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? -
7. Re: UI independent conversation and Seam managed persistence
t.skultinas May 26, 2006 9:28 AM (in response to t.skultinas)Any ideas except application managed entity managers?
-
8. Re: UI independent conversation and Seam managed persistence
gavin.king May 26, 2006 10:51 AM (in response to t.skultinas)Well, you knocked my idea on the head, in my view prematurely :-)