Re: [DISCUSS] getPersistenceManagerProxy

[Craig L Russell]

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.

real PM before/after
deassociation in the Thread-local

In a RESOURCE_LOCAL scenario close on the proxy could be propagated to the

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

(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

with other Synchronization objects referencing
the same PM.

it associate the PM with the transaction, but there could be ordering issues

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

the possibility for other env.

TransactionSynchronizationRegistry is required and leaving as a value-add

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?

Craig

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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature