[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-6897) serialization of the EntityManager should be possible

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6897?page=c... ] 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} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira