db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Anzuoni <ganzu...@objectmagic.org>
Subject PersistenceManagerProxy
Date Fri, 02 Mar 2007 17:12:46 GMT
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
works rather well) and I have faced with a chicken and egg problem.
The problem is :

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

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


View raw message