Thanks David for such details (you really should blog about this ;o)
My concern is not on the clustering side of it but on conversations. I
worked on 2 projects that needed conversations really heavilly. Quite
complex, but thanks to Spring WebFlow we managed to make it happen. We
needed nested conversations (nested flows in Spring WebFlow terminology)
and it's so good to see Spring WF handling that. I don't know the internal
hack of Spring WF but it can serialize one entity manager while you go to a
sub conversation, and deserialize it later. Unfortunattely you can't have
nested conversations in CDI. And if serializing an EntityManager is not
possible, you will not be able to do it either in CDI 1.1 in a standard way.
Antonio
On Fri, Apr 27, 2012 at 05:16, David Blevins <david.blevins_at_gmail.com>wrote:
>
> On Apr 26, 2012, at 7:19 AM, Antonio Goncalves wrote:
>
> > I don't know the technical constraints but I never understood why
> EntityManager was not designed to be serializable.
>
> I can fill in some details.
>
> There's a hard limit with regards to transactions. An EntityManager
> participating in a transaction will be tied to a db connection that will in
> turn be shared by everyone in the transaction and have state shared between
> that connection and the database. There's no point during a transaction
> that you can move that unit of work to another thread or machine.
>
> So this is why an @Stateful bean participating in a transaction cannot be
> passivated/activated. When we add @Transactional support to CDI, we'll
> want the same restriction.
>
> Transactions aside, when we created JPA in EJB 3.0 it was explicitly
> discussed if an EntityManager should be serializable and unanimously deemed
> a bad idea. At least as a requirement. It was generally felt that a
> PersistencProvider should only be required to support persisting state to a
> database and persisting state to a non-database was outside the scope of
> the spec. Vendors are allowed to support clustered/distributed caches, but
> that's not a requirement.
>
> So this is why an @Stateful bean with an EXTENDED EntityManager cannot be
> passivated/activated. Again, something we would have to consider in CDI
> should someday support for EXTENDED persistence contexts be added to the
> feature list.
>
> Storing entities for an extended period of time and/or replicating state
> across a cluster is definitely not as simple as implied in Mark's blog
> post. You can't open up a ObjectOutputStream and write an EntityManager.
> Real caching is far harder than that.
>
> There is an aspect to all of this that confuses people like crazy and that
> is that references to an EntityManager are created by the container appear
> to be serializable by virtue that an @Stateful bean holding the reference
> can at some point be passivated.
>
> The trick here is that the actual EntityManager instance a container
> supplies to a bean via lookup or injection is not a real EntityManager. It
> is simply a wrapper that delegates to whatever the real EntityManager is
> associated to that Transaction. There will be many of these and they will
> come and go frequently.
>
> When so when you take the two passivation requirements together:
>
> - An @Stateful bean cannot be passivated in a transaction
> - An @Stateful bean with an EXTENDED persistence context cannot be
> passivated
>
> You see we surgically eliminated the possibility of passivating a bean
> instance while the bean might be holding an EntityManager wrapper that is
> pointing to a real EntityManager. The bean (and EntityManager wrapper) can
> safely be passivated in all other scenarios.
>
> In terms of CDI beans and passivation and EntityManager references, the
> same concerns exist and we should probably address them. It was really an
> oversight that we didn't do it previously.
>
> Another interesting note on this topic is that passivation/activation is
> not a spec requirement and is not tested in the TCK. The spec details how
> passivation/activation must happen if it is supported, but does not detail
> any situation in which passivation must occur.
>
> Seeing a passivation requirement in JPA would be unlikely.
>
>
> -David
>
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
Blog <http://feeds.feedburner.com/AntonioGoncalves> |
LinkedIn<http://www.linkedin.com/in/agoncal>| Paris
JUG <http://www.parisjug.org>