openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From areider <>
Subject Re: Avoiding detachment, aka Open Session in View
Date Fri, 29 Jul 2011 12:27:49 GMT
Is OSIV with a stateful EJB reliable? What happens, when under load (or
otherwise), the container decides to passivate the stateful bean. Would that
event be completely transparent to a conversation that is using the bean,
the PC, and managed entities therein? 

The Seam project appears to recognize that there is a problem with a PC
surviving passivation. see

Seams solution from what i can gather, is to stash a reference to the PC at
the end of an invocation on the bean, and restore the reference on the next
invocation. The fact that the Seam project found it necessary to do this
rather than leave it to the container raises a big red flag.

IBM discusses the problem here

but their solution appears to be focused preventing the passivation from
failing as opposed to preserving the PC.

It would seem to me that the only reliable thing to do would be to ensure
that passivation is veto'd for the bean, as passivating the bean in such a
way that it could be seamlessly activated and the PC restored, on a lazy
init event sounds like a very hard problem.

Adam Bien, in his post
answers the issue with (the somewhat glib) "just disable passivation. It
isn't needed and possible on most application servers I know...".  (We are
on WAS 7).

I'm not sure if passivation can be disabled and at which level, eg all
beans, specific bean type or specific instance.

This portion of the EJB spec (JSR 220):

A container must not passivate a stateful session bean with an extended
persistence context unless the
following conditions are met:
• All the entities in the persistence context are serializable.
• The EntityManager is serializable.

suggests to me another possibility: just arrange that the PC always contains
some entity that is not serializable. A bit of a hack though ...

I'm also curious how Spring deals with this, since as pointed out by Tobias
in this thread, it offers an implementation of OSIV that might tend to
validate the concept.

View this message in context:
Sent from the OpenJPA Users mailing list archive at

View raw message