I don't have the latest spec version yet. If you do, can you send it to me?
-Tom
Sanjeeb Kumar Sahoo wrote:
>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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>
>
>
--
Tom Ware
Principal Software Engineer
Oracle Canada Inc.
Direct: (613) 783-4598
Email: tom.ware_at_oracle.com