PersistenceManagerProxy

[Guido Anzuoni <ga...@objectmagic.org>]

I have followed with a certain interest JDO-445 issue evolution and
JTA-related discussions.
I have seen with some disappointment that the direction is
to extend PersistenceManagerFactory to include a
getPersistenceManagerProxy() method, so betraying the expected
unawareness of the JDO implementation wrt the proxy functionality.
I have played a little (using jpox 1.2beta1) with a possible "external"
implementation of the proxy functionality (well, in a pre-pre-pre-alpha
stage
works rather well) and I have faced with a chicken and egg problem.
The problem is :
pm.currentTransaction().setOptimistic(b);

where pm is a PersistenceManagerProxy.
In fact, if a JTA transaction is started first, the statement fails
because the "JDO" transaction is active.
If you issue the statement before jta transaction begin, there
is no "current" PersistenceManager: the proxy has no real PM to
call to set the optimistic behaviour.
Well, this problem should be present in CMT too.

A possible solution could be to get a fresh PM from PMF, setting it
to a ThreadLocal (a sort of limbo), trying to attach to the current JTA
transaction on each subsequent call.
But, what if the application calls
pm.currentTransaction().begin()

Should the JDO implementation raise an Exception ?
Should it start a local transaction (in constrast with JTA
TransactionType configuration) ?
What I see to be fragile is the potential inconsistency of the whole
picture.
Let's try to make some order.
1. JTA-bound behaviour at JDO level is specified by TransactionType
2. A JTA-bound PMF must work with a XA DataSource
3. The Proxy and the chicken-and-egg problem

I think that a PMF configured for TransactionType=JTA must not
allow any method invocation that requires datastore access without
an open JTA transaction. This because the underlying DataSource is
a XA DataSource and so there is the possibility of a complete mess
if a JTA is subsequently started (unless JDO impl uses the
ConnectionFactory2Name for local txn).
On top on this sits the proxy with its own "current" association problem
noted before.
Any thoughts ?

Guido