Re: [DISCUSS] Named PMF proposal (JDOHelper enhancements)

[Craig L Russell <Cr...@Sun.COM>]

On Feb 28, 2007, at 8:38 AM, Matthew Adams wrote:

> Inline...
>
>>> Call it what you want -- I only proposed these names.  I
>> wouldn't call
>>> it persistence.xml, as the contents are not the same as the
>>> JPA-specified content.  If the persistence.xml is found, its  
>>> contents
>>> are of course interpretable by the JDO implementation
>> according to our
>>> JPA alignment verbage defined in JDO 2.1.
>>
>> ok. So a JDO2.1 impl has to understand both "persistence.xml"
>> (JPA format) and
>> this "jdo.xml" ? No problem if that is the case but just want
>> to understand
>> what we're specifying here since not everyone was on this conf call.
>>
> Yes, this is correct.  I guess since JPA, which uses the base  
> namespace
> "javax.persistence" and calls the file "persistence.xml", then we  
> should
> probably call JDO bootstrap file "jdo.xml".  Done.

I like it.

>
>>>> We could use the
>>>> same boot idea as JPA and have a
>> META-INF/services/javax.jdo.XXX file
>>>> defining the PMF(s) available, and it takes the one that
>>>> claims it supports
>>>> the required "persistence-unit" (or PMF)
>>>
>>> I like this suggestion!  I assume the following would be
>> true -- please
>>> correct where I've got it wrong.
>>>
>>> * The name of this file is
>>> "META-INF/services/javax.jdo.PersistenceManagerFactory"
>>> 	* This is a text file
>>> 	* The contents of the file would be the name of the provider's
>>> implementation class of javax.jdo.PersistenceManagerFactory
>>
>> Yes. See a mail by Erik to the lists on 19/01/2007 called
>> "Proposal for
>> Service Discovery". JDOHelper would then have the job of
>> finding all services
>> files of this name ("javax.jdo.PersistenceManagerFactory"),
>> and from the
>> contents finding the relevant PMF to instantiate for a
>> particular PMF name.

Ok.
>>
>>
>> Since this appears to be an extension to JDO and not the
>> simple mapping across
>> of terminology JDO-JPA (being able to read a
>> "persistence.xml"), I'd ask are
>> we just confusing users by having "persistenceUnitName" and
>> "transactionType"
>> for when a JDO impl reads a "persistence.xml", yet here we
>> also have a PMF
>> name (which is the same as a persistence-unit name) for when
>> we use this
>> file.
>>
> This was brought up on the conference call.  A "persistence unit"  
> is the
> same thing as a "named PMF".

Yes.

> We decided that we won't use the term
> "named PMF" in the specification -- we'll just go with "persistence
> unit".  There will be a JPA flavor (already specified) and a
> corresponding JDO flavor (adding a name to a PMF, the getName()  
> method).
>
> As far as transaction type, I think they're the same.

There is nothing in JDO 2.0 that corresponds to JPA TransactionType.  
We're adding it to JDO 2.1. So there is no ambiguity and no reason I  
can think of to create a different name.

Craig

> Craig, can you
> please comment on transaction type?
>
> -matthew

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!

RE: Named PM in addition to named PMF

[Matthew Adams <ma...@xcalia.com>]

Hi Christian,

This smells like the userObject property/map allowable on the PM that
was present in JDO 1.0 and expanded in JDO 2.0.  The only difference, if
I understand what you're saying, is that you would be able to get a PM
from a PMF by userObject, yes?

If so, this would require a method overload on PMF:

PersistenceManager getPersistenceManagerByUserObject(Object userObject);

Or something like this.  Questions:

* This would require that all PMFs maintain a map of PMs by userObject,
yes?  Is that reasonable to expect from implementations, or do we
consider another JDO option like
"javax.jdo.option.SupportsKeyedPersistenceManagers"?
* What would the PMF return if there were no userObject at that key in
the map?  Null?
* How does this complement or conflict with the proposed PMF method
getPersistenceManagerProxy()?  Is that sufficient?  They smell kind of
similar to me.

-matthew


>-----Original Message-----
>From: Christian Ernst [mailto:cernst@versant.com] 
>Sent: Wednesday, February 28, 2007 10:40 PM
>To: JDO Expert Group
>Cc: jdo-dev@db.apache.org
>Subject: Named PM in addition to named PMF
>
>Hi JDO friends !
>
>Following the discussion about named PMF,
>i would like to suggest to add also a name to PM.
>
>I think there are cases where it would be helpful to have a named PM.
>For Example:
>A named PM allows to track its PM / TXN via logging up to the Database 
>Server ( assuming the Database Server allows somehow named TXN )
>It would allow explicit lookup via name from the PMF of a PM like
>JDOHelper.getPersistenceManagerFactoryByName("logistic").get.ge
>tPersistenceManagerByName("warehouseexit");
>
>
>Versant has already a vendor extension to set the name of the PM.
>The name is used in Backend Transaction and allows Customer
>much easier to track problematic long running or blocking Transactions
>and find the corresponding code in there Application.
>
>cheers
>Christian
>
>
>
>
>

Named PM in addition to named PMF

[Christian Ernst <ce...@versant.com>]

Hi JDO friends !

Following the discussion about named PMF,
i would like to suggest to add also a name to PM.

I think there are cases where it would be helpful to have a named PM.
For Example:
A named PM allows to track its PM / TXN via logging up to the Database 
Server ( assuming the Database Server allows somehow named TXN )
It would allow explicit lookup via name from the PMF of a PM like
JDOHelper.getPersistenceManagerFactoryByName("logistic").get.getPersistenceManagerByName("warehouseexit");


Versant has already a vendor extension to set the name of the PM.
The name is used in Backend Transaction and allows Customer
much easier to track problematic long running or blocking Transactions
and find the corresponding code in there Application.

cheers
Christian