db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: [DISCUSS] getPersistenceManagerProxy
Date Fri, 16 Feb 2007 00:36:44 GMT
Hi Guido,

Thanks for your comments.

On Feb 12, 2007, at 4:39 AM, Guido Anzuoni wrote:

> 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

Yes, this is a good idea and I'll incorporate this into the  

> (why an implementation specific variable ?
> Is it really needed to be implementation specific ?)

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.

> In a JTA scenario things get a little complicated.
> The real PM could be closed by a Synchronization.afterCompletion()
> registered byPersistenceManagerProxy

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.

> when
> it associate the PM with the transaction, but there could be  
> ordering issues
> with other Synchronization objects referencing
> the same PM.

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.

> 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.

Yes, this is a proof-of-concept that is currently not complete, and  
will be reimplemented during the completion of JDO 2.1.

> 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).

Sure, if an impl already knows how to implement this feature, they  
need not take any code from here.

> Is it possible to design an architecture where  
> getPersistenceManagerProxy()
> delegates to PersistenceManagerProxyProvider ?

I don't see the need for this. If an implementation already has a  
proxy of their own design, they will simply return it.

> Is it possible to add to the spec that PMF impl must not rely on a
> particular PersistenceManagerProxyProvider impl?

The implementation is responsible for implementing  
getPersistenceManagerProxy. There is nothing else that is needed to  
say in the specification.

> Guido

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!

View raw message