[hibernate-dev] HHH-7018 and one more change to how we serialize EntityManagerFactory instances...

[Scott Marlow]

On Tue, Feb 7, 2012 at 9:08 AM, Steve Ebersole <steve at hibernate.org> wrote:

> How is actually, physically serializing a EMF *instance* to another VM
> a valid use case?  Notice that the case of writing the UUID/name to the
>

Good question, I was thinking of the following two cases with container
managed usage:

1.  In a standalone application. some stateful session bean has a
"@PersistenceUnit(unitName = "mypu") EntityManagerFactory emf;" field and
the stateful bean gets passivated/serialized.  The standalone application
server terminates and starts up again in a new jvm.  The passivated
stateful session bean is activated and brought back into the JVM.  When the
EMF is deserialized, the EMF (created during application deployment) is
looked up via its SESSION_FACTORY_NAME or persistence unit name.

2.  In a clustered application, some stateful session bean has
a "@PersistenceUnit(unitName = "mypu") EntityManagerFactory emf;" field and
the stateful bean gets replicated to other cluster nodes.  Later, a
failover occurs and the stateful bean gets deserialized on one of the other
cluster nodes to be used in an invocation on the stateful bean.  When the
EMF is deserialized, the EMF (created during application deployment) is
looked up via its SESSION_FACTORY_NAME or persistence unit name.



> serial stream is explicitly different that this.  That approach is just
> tokenizing the way to resolve the proper reference to the EMF on deser
> using that UUID/name.
>

Regarding what actually happens, yes, no state is serialized.  I think an
improvement would be to track serializable state separately from the
nonserializable objects.



>
> So what is the actual valid use case for "duplicate
> EntityManagerFactory [creation]" on ser/deser?  To me, on deser you
> resolve the name reference if possible; if not, you resolve the UUID
> reference; otherwise, you throw an error.  This is exactly what we do
> with SessionFactory btw in terms of ser/deser.  Why is that not the
> process here?
>

The UUID approach doesn't work with non-JBoss AS clustered applications,
since the UUID wouldn't be well known across the cluster.  The persistence
unit name and the session factory name can be well known across the
cluster.

The use case for duplicate EntityManagerFactory, would be the application
that is depending on the persistence unit name that may or may not be
unique across multiple application deployments.  This could be an
application managed entity manager or a container managed (non-JBoss AS)
use case.



> On Mon 06 Feb 2012 10:32:01 PM CST, Scott Marlow wrote:
> > Feedback is welcome on a proposed change for HHH-7018
> >
> https://github.com/scottmarlow/hibernate-orm/commit/007e7f17eed10c6c1db55a7d9c90b7126c5a5ae2
> >
> > When we serialize the EntityManagerFactory in 4.0.0, there can be
> > nonserializeable objects in the EMF configuration properties (e.g.
> > JTA_PLATFORM, datasource, other stuff).  In most cases, we will have a
> > session factory name (preferred) or persistence unit name to uniquely
> > identify the EntityManagerFactory.  In 4.0.1, during serialization, we
> > only serialize the (hopefully) unique name.
> >
> > If a duplicate EntityManagerFactory is created (by name), no immediate
> > error is given, instead we only give an error later when deserializing
> > the EMF. The HibernateException thrown during deserialization will look
> > like:
> >      "registry contains more than one (" +
> >       entityManagerFactorySet.size()+ ") entity manager factories: "
> >       + name
> >
> > If that causes issues for any application, the SESSION_FACTORY_NAME can
> > be passed in from the troubled application (possibly with
> > SESSION_FACTORY_NAME_IS_JNDI set to false but true is also fine).
> >
> > For the 4.1 release, I would like to take this one step further.  The
> > above changes, only were made for EntityManager serialization of the EM
> > to EMF reference.  The next step is to apply the same change to the EMF
> > readObject/writeObject, such that we also allow the EMF to be serialized
> > when it contains nonserializable objects.  This also simplifies the EM
> > serialization, as it can just use default serialization for the EMF.
> >
> > The proposed commit (to be fixed in 4.1) is at
> >
> https://github.com/scottmarlow/hibernate-orm/commit/007e7f17eed10c6c1db55a7d9c90b7126c5a5ae2
> .
> >
> > Feedback on the change is welcome (we are building 4.1 final middle of
> > this week).
> >
> > Scott
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> --
> steve at hibernate.org
> http://hibernate.org
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>