Hi Tom,
Tom Ware wrote:
> Hi Sahoo,
>
> I have talked to Mike and also passed on your feedback.
Thanks.
> 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.
In the latest version of spec, it has been clarified and it is inline
with our container implementation.
> As I mentioned when I initially updated this bug, we will address this
> issue when the spec has been clarified.
>
Can we get this bug fixed before our hard code freeze which is in a
week's time?
Thanks,
Sahoo
> -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.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>