Web Beans RI and equivalent (if any) to SMPC?
gonorrhea Jun 5, 2009 7:43 AMDoes the Web Beans RI have an equivalent to Seam-managed persistence context? (I have a feeling the answer to this is no but Seam 3 does).
In particular, referring to figure 9.1 in Seam in Action (DAllen), we note the independence of a Seam-managed persistence context with the coupling of the container-managed persistence managers to their stateful session bean components.
So currently in Seam 2.x, the options for an EntityManager (which manages a PC) are the following in an EE envmt using session beans (typically SFSB) to model the conversations:
- transaction-scoped, container-managed
- extended, container-managed
- extended, Seam-managed (SMPC)
According to JPA (Mike Keith), we believe that container-managed, transaction-scoped entity managers are the best model for most applications.
I myself (and I'm sure GKing and rest of JBoss/Seam core team) have doubts about the above comment. Entity detachment after tx commits, potential lazy-loading exceptions during object navigation in JSP/JSF, etc.
My question is this:
whether it's Seam 2, Seam 3, or Web Beans RI, if you need to ensure atomic conversations in a scenario with three conversation-scoped SFSBs, each one serving as a backing bean for a separate form on the same page, is it best to not use SMPC with manual flush (or equivalent in Web Beans)?
If you use Hibernate MANUAL flush mode with SMPC to achieve atomic conversation, the problem is that if you only have one SFSB, any manual flush() of the PC will cause updates to managed entities in all three forms to happen if the entities are dirty aka write-behind (when you only want one form to be updated!) You lose isolation and the symptom is premature updates to entities that were not supposed to be updated/synchronized. If you use AUTO (default) flush, the PC is flushed when tx commits after completion of SFSB business method (assuming there is no JPAQL query in the method, in which case the persistence provider may flush before the query).
So to fix this in Web Beans or Seam 3, would a good solution be to break the SFSB into three SFSBs (one per form in the facelet/JSF page) and use @PersistenceContext, either tx-scoped or extended type, rather than @In EntityManager entityManager (SMPC) with one SFSB?
JPA (Mike Keith): Extended entity managers work with a single persistence context that is tied to the life cycle of a SFSB.
Does that mean that if you use @PersistenceContext(type=PersistenceContextType.EXTENDED) in more than one SFSB, each one is unique and manages a different set of entities?
Whereas in the case of SMPC, everytime it is injected in a Seam component, it is managing the same set of entities as its reference in another Seam component.
Well I guess it would be easy enough to prove this by doing a em.contains() in each SFSB and see if a particular entity is contained in more than one SFSB/PC or not...