Marina Vatkina wrote:
>Hi Tom,
>
>I just talked briefly with Linda about this, and it looks like there is some
>amount of confision about which name we are refereing to.
>
>There is (1) a PU name as defined in persitence.xml.
>There is also (2) a name as defined in @PU or @PCtx annotation.
>
>#2 is unique in an app (yes?)
>
There are two different names in a PersistenceUnit/PersistenceContext
environment dependency. One is the name that identifies the dependency
itself within a Java EE component environment (java:comp/env). That
name only has to be unique within the defining App Client, .war, or ejb
component. It's specified using the name() attribute or
persistence-unit-ref-name/persistence-context-ref-name .xml elements.
The other is the unitName attribute or persistence-unit-name .xml
element, which is used to resolve the target persistence unit within the
module / .ear. It can either be unspecified, an unqualified unitName
("unit1"), or a fully-qualified name ("../persistence1.jar#unit1").
>#1 is unique in a scope of this PU.
>
>May be the name should be renamed :).
>
>thanks,
>-marina
>
>Tom Ware wrote:
>
>
>
>>Hi Sahoo,
>>
>> I have talked to Mike and also passed on your feedback. In addition,
>>he has had some discussions with Linda in parallel with these emails.
>>They are definitely going to clarify this issue in the next version of
>>the spec. As I mentioned when I initially updated this bug, we will
>>address this issue when the spec has been clarified.
>>
>>-Tom
>>
>>Sanjeeb Kumar Sahoo wrote:
>>
>>
>>
>>>Hi Tom,
>>>
>>>Tom Ware wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Hi Sahoo,
>>>>
>>>>>From the container point of view, how does redeployment happen?
>>>>
>>>>
>>>>
>>>>
>>>Container is supplied an application name which is unique in the
>>>container. From there, we look up the application object where PUs are
>>>arranged in a hierarchy, not in a flat structure. Container first
>>>unloads the earlier application then loads the new one. In the process,
>>>we call emf.close() first then call createEMF().
>>>
>>>
>>>
>>>
>>>
>>>>By section 5.3 of the spec (footnote 32) there can only be one entity
>>>>manager factory per persistence unit.
>>>>
>>>>
>>>>
>>>>
>>>Agreed. The way I read it is that it says per PU. Container instantiates
>>>persistence units by reading entries from persistence.xml. So where is
>>>name coming into picture? More over in the EJB 3 Core contracts proposed
>>>final draft (section #15.10.2) as well as in Java EE 5 platform spec
>>>(section #5.13.2) proposed final draft, they specifically mention about
>>>using fully-qualified-syntax for referring to persistence units. e.g.
>>>
>>>@PersistenceContext(lib/*par1*.jar#Foo) EntityManager em1;
>>>
>>>@PersistenceContext(lib/*par2*.jar#Foo) EntityManager em2;
>>>
>>>This is similar to the syntax used for referring to EJBs.
>>>
>>>
>>>
>>>
>>>
>>>>This means that when a create is called, we need a way to determine if
>>>>something is a redeploy or an initial deploy.
>>>>
>>>>
>>>>
>>>>
>>>Why does a persistence provider care? I agree that provider can't figure
>>>out redeployment, but container can. So during redeployment, container
>>>should call *emf.close() followed by createEMF()*. When emf.close() is
>>>called, provider can do all necessary clean up. *In fact relying on name
>>>is so incorrect because if an application is redeployed with changed PU
>>>names, then all the old PUs would still be hanging around!*
>>>
>>>
>>>
>>>
>>>
>>>>Looking at the last paragraph of section 7.1.1 of the spec, it says
>>>>that createContainerEntityManagerFactory() is the way to cause a
>>>>redeployment to occur.
>>>>
>>>>
>>>>
>>>>
>>>I see your point. IMHO, If any line in the spec needs to be reworded,
>>>then this is the line. It should mandate that during redeployment,
>>>container must call emf.close() for all the old EMFs. In glassfish, we
>>>actually call emf.close() during redeployment.
>>>
>>>My $0.02.
>>>
>>>Thanks,
>>>Sahoo
>>>
>>>
>>>
>>>
>>>
>>>>If only the name is provided, how does the persistence provider
>>>>distinuguish between an initial deploy and a redeploy?
>>>>We thought of using the ClassLoader as a way to uniquely identify
>>>>things, but the spec does not guarantee that the class loader will be
>>>>the same on each call, so the ClassLoader is eliminated as a way to
>>>>identify things.
>>>>
>>>>-Tom
>>>>
>>>>
>>>>Sanjeeb Kumar Sahoo wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>Hi Tom,
>>>>>I really don't understand why does provider care about the name?
>>>>>Container is responsible for resolving PU names and calling
>>>>>provider.createEMF() appropriately. Container calls emf.close()
>>>>>during redeployment. So would you mind explaining why TopLink needs
>>>>>to know what is the name of the PU?
>>>>>
>>>>>Thanks,
>>>>>Sahoo
>>>>>Tom Ware wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Sahoo,
>>>>>>
>>>>>>I just had a quick chat with Mike Keith. And he is hoping we can
>>>>>>come up with some ideas about how to uniquely identify the PU (since
>>>>>>the name is not unique as mentioned below). When we come up with a
>>>>>>good solution, it will be brought up as part of the spec discussions.
>>>>>>
>>>>>>Our initial suggestion is that the container provide some kind of
>>>>>>identifier to the persistence provider in the PersistenceUnitInfo.
>>>>>>This could possibly be a String pointing to the location of the
>>>>>>persistence unit, a URL, or some other String that uniquely
>>>>>>identifies the persistence unit when used in conjunction with the name.
>>>>>>
>>>>>>What do you think? Do you have any suggestions?
>>>>>>
>>>>>>Thanks,
>>>>>>Tom
>>>>>>
>>>>>>Tom Ware wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>The problem is that based on the information available, there is no
>>>>>>>way to uniquely identify the PU and since the spec says that if we
>>>>>>>call this method with the same PU, we have to redeploy, there is
>>>>>>>know way to know which path to take. I have been told the spec
>>>>>>>comittee is discussing this.
>>>>>>>
>>>>>>>-Tom
>>>>>>>
>>>>>>>Sanjeeb Kumar Sahoo wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi Tom,
>>>>>>>>I don't know what is the confusion here. Any way, can't we at
>>>>>>>>least fix such that PU names does not have to be unique across the
>>>>>>>>JVM?
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>Sahoo
>>>>>>>>tware_at_dev.java.net wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>https://glassfish.dev.java.net/issues/show_bug.cgi?id=78
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>------- Additional comments from tware_at_dev.java.net Thu Dec 8
>>>>>>>>>13:57:26 +0000 2005 -------
>>>>>>>>>The spec will be providing clarification about this issue. We
>>>>>>>>>will make changes when the new information is available.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
>
>