ManagedPersistenceContext and passivation

[gonorrhea]

The following is from the ManagedPersistenceContext source code:

   /**
    * If a transaction is active, fail the passivation. The field holding the
    * managed EntityManager is marked as transient so that it is not serialized
    * (it can't be). The transient keyword was choosen because we don't want to
    * forcefully close and nullify the EntityManager on every request because
    * then we have to keep hitting the database to load the entities back into
    * the persistence context. The only downside is that we cannot clean up
    * on the old node before the session hops, but it turns out not to matter.
    * 
    * Note that we must use the method on the
    * {@link HttpSessionActivationListener} interface rather than
    * <code>@PrePassivate</code> since interceptors are disabled on this component.
    */
   public void sessionWillPassivate(HttpSessionEvent event)
   {
      if (synchronizationRegistered)
      {
         throw new IllegalStateException("cannot passivate persistence context with active transaction");
      }
   }

So I searched the Seam codebase for sessionWillPassivate and found only 3 hits.

1) What class(es) and method(s) is/are calling the above sessionWillPassivate() method?

2) What exactly is the context of this comment above?  Does it refer to cases where a typical CONVERSATION-scoped SFSB modeling a LRC is passivated to disk by the EJB container?  This component is a JavaBean, so I'm a little unclear about what is going on here and what the concern is regarding passivation.

Let's say you have 3 SFSBs that are conversation-scoped, all of which are using SMPC (the same SMPC obviously).  So if one of the SFSBs is passivated by the EJB container, is this the same scenario that is described above in the code comment?

Any elaboration here is appreciated.

[kapitanpetko]

Arbi Sookazian wrote on May 18, 2009 07:40:


1) What class(es) and method(s) is/are calling the above sessionWillPassivate() method?

ManagedPersistenceContext implements HttpSessionActivationListener, so it's being called by the Servlet container.
It gets called on session passivation and replication (in a cluster).

2) What exactly is the context of this comment above?  Does it refer to cases where a typical CONVERSATION-scoped SFSB modeling a LRC is passivated to disk by the EJB container?  This component is a JavaBean, so I'm a little unclear about what is going on here and what the concern is regarding passivation.

You shold probably ask Dan Allen about the comment, but Cf. JBSEAM-3728

Since the SMPC lives in the session, any SMPC related cleanup/init is done on session passivation/activation. SFSB passivation has
nothing to do with this.

A bit OT, I was having trouble with the IllegalStateException being thrown when, say, a search is in progress, thus breaking session replication. I chose to override the component and not throw, and that works for me, although this is probably not ideal.

The whole SMPC in a cluster affair is a bit undocumented and probably not well specified (or I am missing something...)

HTH

[gonorrhea]

Nikolay Elenkov wrote on May 18, 2009 10:07:


The whole SMPC in a cluster affair is a bit undocumented and probably not well specified (or I am missing something...)

You're right.  Perhaps an advanced topic but that needs a sticky and/or knowledgebase treatment.