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

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.

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?

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/007e7f17eed10c6c1db55... > > 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/007e7f17eed10c6c1db55... . > > Feedback on the change is welcome (we are building 4.1 final middle of > this week). > > Scott > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev -- steve(a)hibernate.org http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

(For whatever reason, I still don't understand why EMF clustering would be different than SF clustering.)

It wouldn't be difficult to switch back to using UUIDs in the EMF. Neither way is perfect (see discussion on HHH-6897). On 02/08/2012 08:28 AM, Steve Ebersole wrote: > > On 02/08/2012 04:23 AM, Christian Bauer wrote: >> >> (For whatever reason, I still don't understand why EMF clustering would >> be different than SF clustering.) > > > This is exactly the point I am missing here as well. >

I'll set the EntityManagerFactory name to: (1) explicit AvailableSettings.SESSION_FACTORY_NAME if specified (2) use application specified pu-name if pu-name is specified (not always the case, especially in test environments) (3) uuid On 02/08/2012 11:08 AM, Steve Ebersole wrote: > If I understand correctly you are thinking there is a case where the > "PU name" would not be unique for a given app? That is the only time > I can see this being a concern. If it is possible that the same app > can have different PU names on different nodes in the cluster then > simply using PU name as EMF name wont work there. But pretty sure I > said that this will need to allow explicitly setting of the EMF name. > > But regardless UUID will never work in a cluster. Thats been covered > a few times here. UUID is merely a fallback which assumes ser and > deser happen in the same VM. > > On Wed, Feb 8, 2012 at 9:17 AM, Scott Marlow<smarlow(a)redhat.com> wrote: >> It wouldn't be difficult to switch back to using UUIDs in the EMF. >> Neither >> way is perfect (see discussion on HHH-6897). >> >> >> >> On 02/08/2012 08:28 AM, Steve Ebersole wrote: >>> >>> On 02/08/2012 04:23 AM, Christian Bauer wrote: >>>> >>>> (For whatever reason, I still don't understand why EMF clustering >>>> would >>>> be different than SF clustering.) >>> >>> >>> This is exactly the point I am missing here as well. >>> >>