Hi Erik, On Oct 9, 2006, at 11:33 AM, Erik Bengtson wrote:
what if two PMFs have txs on the same thread?
The proposal would involve two proxies to two PMFs, each of which would get a thread-associated or transaction-associated PM from its own factory.
Could the persistent-unit from JPA concept be applied?
like:
JDOHelper.getPersistenceManager("persistent-unit1")
JDOHelper.getPersistenceManager("persistent-unit2")
So far, we have avoided naming the PersistenceManagerFactories. But in any case, the idea is to avoid getPersistenceManager except just once. Did you mean:
JDOHelper.getPersistenceManagerProxy("persistent-unit1")
JDOHelper.getPersistenceManagerProxy("persistent-unit2")
We can certainly add a property to PMF: javax.jdo.PersistenceUnitName
that corresponds to the concept in JPA.
Craig
Quoting Craig L Russell <[EMAIL PROTECTED]>:Javadogs, I'd like to propose a solution to a problem that we have with usability in the web tier. When using a servlet, each method that needs access to a PersistenceManager needs to figure out where the current PersistenceManager is, and if it is even active. There are many ways around this issue, but they are not general. Among the workarounds are putting the active PersistenceManager into the servlet context as a request or session attribute, passing the PersistenceManager explicitly as a parameter, and putting the PersistenceManager into a ThreadLocal field. Of these workarounds, the one with the most appeal is the ThreadLocal solution. So I'd like to propose that we formalize this by adding a method to return a thread-safe PersistenceManager proxy associated with a PersistenceManagerFactory that can be implemented as a singleton, stored in a component's static field, and that dynamicallybinds to the PersistenceManager that is currently active on the thread.Multiple PersistenceManager proxies can be active, each with its own binding to a (possibly different) PersistenceManagerFactory. The benefit of this proposal is ease of use for web and ejb components that currently have to manage their own PersistenceManager resources. Instead of having to look up and store a PersistenceManager in each method of each component that needs one, looking up the PersistenceManagerFactory can be done once during initialization of the component. The limitations of the proposal is that in environments that do not support Java EE 5 TransactionSynchronizationRegistry (i.e. J2SE servers and Java SE), only one PersistenceManager per PersistenceManagerFactory can be used per thread (which maps to a single web request), and only one transaction can be used per PersistenceManager. In environments that support Java EE 5 TransactionSynchronizationRegistry, container-managed transactions can be used, including the ability to suspend transactions. If used in an environment that does not support Java EE 5 TransactionSynchronizationRegistry, the behavior is as follows: The first component to use a PersistenceManager method on a thread would get a PersistenceManager from the factory. Subsequent callers would use the same PersistenceManager delegate until the transaction completed, at which time the PersistenceManager is cleared and the first subsequent request would create a new one. Implementation: The proxy would delegate most methods to the current PersistenceManager, as determined by the ThreadLocal field being non- null. Calling close() would have no effect. If the ThreadLocal field is null, then getPersistenceManager() would be called on the PersistenceManagerFactory. A synchronization instance would be created and registered with the currentTransaction of the newly acquired PersistenceManager, the PersistenceManager would be set into the ThreadLocal, and then the request wold be delegated to the new PersistenceManager. At afterCompletion, the ThreadLocal would be nullified. If used in an environment that supports Java EE 5 TransactionSynchronizationRegistry, the behavior is as follows: The first component to use a PersistenceManager method in a managed transaction would get a PersistenceManager from the factory. Subsequent callers in the same transaction would use the same PersistenceManager delegate until the transaction completed, at which time the PersistenceManager is cleared and the first request in a new transaction would create a new one. Implementation: The proxy would delegate most methods to the current PersistenceManager, as determined by the TransactionSynchronizationRegistry entry for the PersistenceManagerFactory being non-null. Calling close() would have no effect. If the TransactionSynchronizationRegistry entry for the PersistenceManagerFactory is null, then getPersistenceManager() would be called on the PersistenceManagerFactory. An interposed synchronization instance would be created and registered with the TransactionSynchronizationRegistry, the PersistenceManager would be set into the TransactionSynchronizationRegistry entry for the PersistenceManagerFactory, and then the request wold be delegated to the new PersistenceManager. At afterCompletion, the TransactionSynchronizationRegistry entry for the PersistenceManagerFactory would be nullified. If we agree on the semantics of this behavior, the method can be implemented as a helper method of JDOHelper, PersistenceManagergetPersistenceManagerProxy or something like it (suggestions welcome).To support container-managed transactions in J2EE servers (1.4 and earlier), we would have to put the method on PersistenceManagerFactory and allow the implementation to use its own secret sauce to provide the proper semantics. If the jdo implementation chose, it could simply delegate to the JDOHelper version of the method, with the limitations therein. Craig Craig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
