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.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>