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?)
#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.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>