[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-6897) serialization of the EntityManager should be possible
Emmanuel Bernard (JIRA)
noreply at atlassian.com
Mon Dec 19 06:28:21 EST 2011
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44619#comment-44619 ]
Emmanuel Bernard commented on HHH-6897:
---------------------------------------
I'm -1 on UUID as by definition it does *not* solve the cluster problem you are trying to fix.
I'm attaching the logs of the discussion we had on UUID vs pu name
{quote}
emmanuel: Hi Scott I don't follow you reasoning
emmanuel: https://hibernate.onjira.com/browse/HHH-6897?focusedCommentId=44600
emmanuel: "Even with containers that know to pass in the unique EMF name, application managed entity managers will not likely specify the unique EMF name. So, I agree that defaulting to UUID covers more cases."
smarlow: the part about using uuid?
emmanuel: So all app managed PU will *not* work in a cluster *for sure*
emmanuel: as a UUID will be generated
emmanuel: Actually application managed entity managers work just like container managed entity managers. It's more app managed EMF vs container managed EMF
emmanuel: but even that, all EMF defined in a persistence.xml should be deployed by the container
emmanuel: so all are container based
emmanuel: theiur lifecycle I mena
emmanuel: What you are proposing is that in a cluster, if the explicit name is not provided, then we use UUID => clustering won't work in any container besides Jboss AS, let's be realistic about that
emmanuel: I agree the PU name is not "unique enough" pontentially but we could definitely raise a warning in this case (ie recording two different instances of EMF under the same name
smarlow: is it a warning or a deployment error ?
smarlow: as long as closing the emf, doesn't close the wrong em, its just a warning
emmanuel: I feel that a deployment error could be too constraining
smarlow: a warning is fine, if closing the emf, doesn't close the wrong em
smarlow: I think we talked recently about what happens when the emf gets closed. didn't you say that the em isn't referenced from the emf?
emmanuel: Well what we can do is the following, if two emf are found with the same name, we register them and when unserializing an EM fron that name, we can raise a deserialization error explaining two EMF are registered with the same name
emmanuel: that way we can do the warning ahead of time
emmanuel: and the be safe for their data
emmanuel: makes ense?
emmanuel: right the EMF has not reference to an EM
emmanuel: So the EM won't find it's EMF (as it's closed) and wont be able to be deserialized
smarlow: that makes sense also (they can change their pu name then)
emmanuel: yes
emmanuel: with a good log / exception text we ahve a win win situation
smarlow: yup, simpler is better and reusing what is already available
emmanuel: ie easy 95% of the time on any container and safe 100% of the time on JBoss AS
smarlow: steve said that we should be able to do a 4.0.1 release next week, after this is fixed
emmanuel: k
emmanuel: cool
smarlow: emmanuel: when we create two EMFs with the same pu name (different application deployments), would we not be putting the EMF pu name into a global map, with the pu name as the key?
smarlow: which would be a problem, as the map would only accept one EMF
emmanuel: no if your map accepts a Set<EntityManagerFactory>
emmanuel: s/no/not/
smarlow: what would be the map key be? the Set<EMF> is the value?
emmanuel: I was thinking Map<String,Set<EMF>>
smarlow: String is the pu name, right?
emmanuel: Where the key is either the specific property passed in when creating the EMF or if not the PU name
smarlow: okay, so we still support a key passed in also
emmanuel: Right so that JBoss AS passes a truly unique PU name on steroid and is always 100% safe and working
emmanuel: But still works 99% of the time on other containers that don't handle Hibernae specifically
smarlow: that makes sense, for app managed entity managers, are used in the cluster, they can either use a unique pu name or specify the property
smarlow: s/for/when
emmanuel: What do you mean by app managed EM?
emmanuel: @Inject EntityManagerFactory factory;
public doStuff() {
EntityManager em = emf.createEntityManager();
…
em.close();
}
?
emmanuel: if that's the case then, these are handled the same as container maanged EM
emmanuel: the property must be passed at the EMF creation
emmanuel: not at the EM creation
emmanuel: ie during PersistenceProvider.createContainerEntityManagerFactory(persistenceUnitInfo, propertiesMap);
smarlow: xchat on Fedora 16 seg faulted (first time since installing F16)
emmanuel: Let me replay
emmanuel: What do you mean by app managed EM?
emmanuel: @Inject EntityManagerFactory factory;
smarlow: I got up to "<emmanuel> ie during PersistenceProvider.createContainerEntityManagerFactory(persistenceUnitInfo, propertiesMap);"
emmanuel: public doStuff() {
EntityManager em = emf.createEntityManager();
…
em.close();
}
emmanuel: if that's the case then, these are handled the same as container maanged EM
emmanuel: the property must be passed at the EMF creation
emmanuel: not at the EM creation
emmanuel: ie during PersistenceProvider.createContainerEntityManagerFactory(persistenceUnitInfo, propertiesMap);
emmanuel: and that's it
smarlow: that makes sense, since even the application managed EMF comes from the PersistenceProvider.createContainerEntityManagerFactory(persistenceUnitInfo, propertiesMap);
emmanuel: yep, exactly
{quote}
> serialization of the EntityManager should be possible
> -----------------------------------------------------
>
> Key: HHH-6897
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6897
> Project: Hibernate Core
> Issue Type: Task
> Affects Versions: 4.0.0.CR7
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Fix For: 4.0.1
>
>
> http://pastie.org/3018508 contains the NotSerializableException: org.hibernate.service.internal.StandardServiceRegistryImpl exception and http://pastie.org/3018879 describes some of contained values that don't appear to be serializable.
> I would like to see this fixed in either 4.0.0.Final or a 4.0.1.Final (if that could happen in time). I'll have more information soon, regarding fix version.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the hibernate-issues
mailing list