Linda, Mike,
Can you please shed some on this discussion? I also don't understand
why the provider needs a unique PU name.
thanks,
-marina
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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >