|
Home > Archive > Apache JDO Project > February 2007 > [DISCUSS] getPersistenceManagerProxy
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
[DISCUSS] getPersistenceManagerProxy
|
|
| Craig L Russell 2007-02-09, 7:11 pm |
| | |
| Erik Bengtson 2007-02-11, 1:11 pm |
| What's RESOURCE_LOCAL? Non JCA?
Quoting Craig L Russell <Craig.Russell@Sun.COM>:
> Please review and comment on this proposed change to the
> specification, as part of the JDO 2.1 maintenance release.
>
> <proposal>
> (PersistenceManagerFactory interface)
> 11.3.1 Access via proxy
> PersistenceManager getPersistenceManagerProxy();
> Returns a PersistenceManager instance that is thread-safe, for use in
> web and application servers and outside servers. The instance
> returned can be used in a servlet init method to initialize a static
> variable in a web server application. Similarly, it can be used in a
> session bean to initialize a static variable in an application server
> application.
>
> If this method is used with a PersistenceManagerFactory that is
> configured with TransactionType JTA, the proxy returned will
> dynamically delegate to a PersistenceManager. The close method on the
> proxy has no effect.
> o If there is a PersistenceManager currently associated with the
> thread’s transaction, the method in the proxy delegates to the
> corresponding method in the PersistenceManager currently associated
> with the thread’s transaction.
> o If there is no PersistenceManager currently associated with the
> thread’s transaction, a PersistenceManager is created and associated
> with the thread’s transaction.
> o If there is no transaction currently associated with the calling
> thread, a new PersistenceManager is created with no transaction
> association, and no possibility of beginning a transaction (in this
> case, the begin method on the Transaction instance throws
> JDOUserException). Persistent instances returned as a result of
> queries can be used to navigate via nontransactional access,
> regardless of whether a transaction is subsequently associated with
> the thread. The PersistenceManager returned from methods
> Query.getPersistenceManager, JDOHelper.getPersistenceManager, and
> PersistenceCapable.getPersistenceManager return the actual
> PersistenceManager to which the proxy delegated the original method.
>
> If this method is used with a PersistenceManagerFactory that is
> configured with TransactionType RESOURCE_LOCAL, the proxy returned
> will dynamically delegate to the PersistenceManager currently
> associated with an implementation-defined thread-local variable. The
> thread-local variable is inherited by any threads created by the
> thread that currently has a PersistenceManager associated with it.
> The close method on the proxy clears the thread local variable to
> null, and a subsequent invocation on the proxy will create a new
> PersistenceManager.
> </proposal>
>
> 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!
>
>
| |
| Andy Jefferson 2007-02-11, 1:11 pm |
| > What's RESOURCE_LOCAL? Non JCA?
See JPA spec 6.2.1.2. Non JTA
--
Andy
| |
| Dain Sundstrom 2007-02-11, 1:11 pm |
| Sounds exactly like the JPA rules, so it makes sense to me. If there =20=
are supposed to be differences in comparison to the JPA rules, I =20
suggest you explicitly call them out due the the extreme similarity =20
between the two in this text.
-dain
On Feb 9, 2007, at 2:00 PM, Craig L Russell wrote:
> Please review and comment on this proposed change to the =20
> specification, as part of the JDO 2.1 maintenance release.
>
> <proposal>
> (PersistenceManagerFactory interface)
> 11.3.1 Access via proxy
> PersistenceManager getPersistenceManagerProxy();
> Returns a PersistenceManager instance that is thread-safe, for use =20
> in web and application servers and outside servers. The instance =20
> returned can be used in a servlet init method to initialize a =20
> static variable in a web server application. Similarly, it can be =20
> used in a session bean to initialize a static variable in an =20
> application server application.
>
> If this method is used with a PersistenceManagerFactory that is =20
> configured with TransactionType JTA, the proxy returned will =20
> dynamically delegate to a PersistenceManager. The close method on =20
> the proxy has no effect.
> o If there is a PersistenceManager currently associated with the =20
> thread=92s transaction, the method in the proxy delegates to the =20
> corresponding method in the PersistenceManager currently associated =20=
> with the thread=92s transaction.
> o If there is no PersistenceManager currently associated with the =20
> thread=92s transaction, a PersistenceManager is created and =20
> associated with the thread=92s transaction.
> o If there is no transaction currently associated with the calling =20
> thread, a new PersistenceManager is created with no transaction =20
> association, and no possibility of beginning a transaction (in this =20=
> case, the begin method on the Transaction instance throws =20
> JDOUserException). Persistent instances returned as a result of =20
> queries can be used to navigate via nontransactional access, =20
> regardless of whether a transaction is subsequently associated with =20=
> the thread. The PersistenceManager returned from methods =20
> Query.getPersistenceManager, JDOHelper.getPersistenceManager, and =20
> PersistenceCapable.getPersistenceManager return the actual =20
> PersistenceManager to which the proxy delegated the original method.
>
> If this method is used with a PersistenceManagerFactory that is =20
> configured with TransactionType RESOURCE_LOCAL, the proxy returned =20
> will dynamically delegate to the PersistenceManager currently =20
> associated with an implementation-defined thread-local variable. =20
> The thread-local variable is inherited by any threads created by =20
> the thread that currently has a PersistenceManager associated with =20
> it. The close method on the proxy clears the thread local variable =20
> to null, and a subsequent invocation on the proxy will create a new =20=
> PersistenceManager.
> </proposal>
>
> 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!
>
| |
| Craig L Russell 2007-02-11, 7:11 pm |
| | |
| Guido Anzuoni 2007-02-12, 1:11 pm |
| It is not clear when the real PersistenceManager will get closed.
In a RESOURCE_LOCAL scenario close on the proxy could be propagated to the
real PM before/after
deassociation in the Thread-local (why an implementation specific variable ?
Is it really needed to be implementation specific ?)
In a JTA scenario things get a little complicated.
The real PM could be closed by a Synchronization.afterCompletion()
registered byPersistenceManagerProxy when
it associate the PM with the transaction, but there could be ordering issues
with other Synchronization objects referencing
the same PM.
Looking at the proposed implementation of getPersistenceManagerProxy() in
issue JDO-445 I have seen that
TransactionSynchronizationRegistry is required and leaving as a value-add
the possibility for other env.
I can obviously wrong, but I think that the whole feature can be implemented
on top of existing impl (well, PMF must support
JTA TransactionType in order to work in a JTA-controlled transactions).
Is it possible to design an architecture where getPersistenceManagerProxy()
delegates to PersistenceManagerProxyProvider ?
Is it possible to add to the spec that PMF impl must not rely on a
particular PersistenceManagerProxyProvider impl?
Guido
| |
| Craig L Russell 2007-02-15, 7:11 pm |
| | |
| Guido Anzuoni 2007-02-21, 7:11 am |
| Craig L Russell <Craig.Russell <at> Sun.COM> writes:
>
> Hi Guido,
>
> Thanks for your comments.
>
> On Feb 12, 2007, at 4:39 AM, Guido Anzuoni wrote:
>
>
> Yes, this is a good idea and I'll incorporate this into the
> specification.
>
>
> The reason to specify the precise ThreadLocal would be to allow users
> to access it directly. We would have to specify the class and
> accessors for the field. This would complicate the specification,
> which is intended to be "just specific enough" to give users
> everything they want without the possibility of hurting themselves.
>
>
> Actually, the real PM would be closed by the afterCompletion
> registered by the real PersistenceManager. The real
> PersistenceManager is automatically de-registered by the behavior of
> TransactionSynchronizationRegistry if that interface is used by the
> implementation, or by an implementation-specific mechanism.
>
>
> I believe that this scenario is covered already in the specification.
> The PM is responsible to call the user's registered Synchronization
> instance during transaction completion. The proxy does not complicate
> this existing usage.
Well, maybe it's too late, but, you know, thinking process might
take some time 
I have some extra comments on closing PM in a JTA scenario.
You say that actually the real PM is closed by the afterCompletion
registered by the real PersistenceManager.
I disagree on this.
PersistenceManager outlives the transaction boundaries, either global or local.
You can have the following usage:
PersistenceManager pm = ...
UserTransaction ut = ...
ut.begin();
pm.makePersistent();
ut.commit();
....
ut.begin();
pm.makePersistent();
ut.commit();
...
pm.close();
In a proxy-based scenario the real PM has a lifecycle that is completely bound
to the (global) transaction lifespan: it is created when the user requires
a PM the first time and is closed by the proxy upon completion
(Synchronization.afterCompletion on the JTA transaction).
This lead to the assumption that:
1. no PM (proxy) can be acquired without an open JTA transaction
2. Synchronization.afterCompletion of the proxy should be called **after** any
other Synchronization that might be registered by the real implementation on
the JTA transaction itself (this is critical because JTA does not enforce any
ordering in Synchronization objects). An alternative to guarantee that
the proxy Synchronization.afterCompletion is invoked after
any "finalization" actions performed by the PM, is to register the synchro
on pm.currentTransaction(), but this would "consume" the only slot available.
This would not be a big problem, because the real pm remains almost hidden
to the app (unless JDOHelper.getPersistenceManager(o) is called).
What I like is the JDO implementations being unaware of PersistenceManagerProxy,
so it is responsibility of the proxy to close the real pm.
Guido.
| |
| Craig L Russell 2007-02-21, 7:11 pm |
| | |
| Guido Anzuoni 2007-02-22, 1:11 pm |
| Craig L Russell wrote:
>
> On Feb 21, 2007, at 12:24 AM, Guido Anzuoni wrote:
>
>
> I think this case doesn't need a proxy at all. The proxy is needed if
> your use case requires binding to a different pm each time, based on
> the existence of a container-managed transaction. If you want to
> manage the life cycle of the pm yourself, and manage transactions
> yourself, there is no need for a proxy.
I think that the proxy could be useful even if the application manages
txn boundaries.
I agree that doesn't make sense if there is a need of managing the PM
lifecycle.
>
> Actually, I've updated the spec such that in the case of using the
> proxy without a JTA transaction, a PM will be created that does its
> work outside a transaction.
I don't know what could happen if, once acquired a PM before, the app
begins a transaction.
What would be the behaviour of the underlying DataSource connection
(considering a SQL store) ?
I think that a proxy cannot be acquired without an open (global)
transaction.
>
>
>
> This is done by containers that implement
> javax.transaction.TransactionSynchronizationRegistry, a new feature of
> Java EE 5. JDO implementations that use non-TSR containers need to
> have a private contract with the container so that the proper ordering
> is done.
I fear that such a container will never be implemented 
>
>
> We looked at allowing users to register multiple synchronizations with
> the JDO Transaction, but concluded that it would be a rare case where
> the synchronizations would truly be independent.
>
>
> The current design does allow the user to get access to the "real PM"
> but I don't think that this is a major problem. Any code that
> deliberately bypasses the proxy usage by storing the real PM and using
> it out of scope will simply get a "PM has been closed" exception.
What could be done is the following:
1. the app requires a proxy (with open txn)
2. the proxy (or a manager) creates the real PM from a PMF with JTA
TransactionType
3. the proxy register a Synchronization on the real PM, so that
afterCompletion will be called **after** all necessary state transitions of
the persistent capable objects have been finalized, and real PM
close() can be safely called.
This will fail if the app overwrites the proxy Synchronization issuing a
setSynchronization() on the real PM.
(OK some WeakHashMap can help for "gc" of unreachable real PM).
>
> Me too.
>
> Craig
>
> 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!
>
|
|
|
|
|