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:[EMAIL PROTECTED] >Sent: Wednesday, February 28, 2007 10:40 PM >To: JDO Expert Group >Cc: [email protected] >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 > > > > >
