| Matthew Adams 2007-03-01, 1:11 am |
| 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]=20
>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=20
>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
>
>
>
>
>
|