Hi David,
On 27.04.2012, at 05:16, David Blevins 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.
Is is impossible because of CAP. Therefore I proposed:
https://java.net/jira/browse/EJB_SPEC-56 in clustered environment I always deactivated passivation of SFSB. Reasons: unpredictable behavior, thrashing and possible performance problems. I always used proprietary server features, so @NotPassivable should be easy to implement.
SFSB with Extended EM could be just annotated with @NotPassivable
Any thoughts?
>
> 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
>