marc fleury wrote:
> |The problem was that the TransactionImpl that came
> |with the invocation of the BMT bean was never
> |imported into the transaction manager (all instances
> |of TransactionImpl should be imported after
> |travelling over RMI, and for CMT this is done
> |implicitly in TxMamager.associateThread())
>
> yes this is the right place to put it, and doing it implicitely is also
> right.
I thought that you didn't like this implicit
transaction import?
I have a problem with it: In all distributed
transaction managers I have seen the transaction
propagation context is different from the local
representation of a transaction.
But not so in our in-VM distributed transaction
manager. Here a Transaction instance is serialized
for passing over RMI, and at the other end of the
connection we get a Transaction instance from
deserialization. But the Transaction instance we
get from deserialization is really useless unless
imported locally. In the first versions of the
code (before I had my hands on it) we were lucky
to have a TxCapsule leak that just made an explicit
import superfluous. To avoid touching other code
than the TM package, I made the import implicit in
the first association to a thread.
This works only because the TransactionImpl is
serializable and holds a reference to the Xid,
and because the XidImpl is serializable.
But now Aaron has added support for using other
Xid implementations than XidImpl, as this is
needed for Oracle XA drivver interoperability.
This means that we risk having a non-serializable
Xid reference in our TransactionImpl.
I would very much prefer that a TransactionImpl
is not passed over RMI in the MI. Instead the
data encapsulated in Xid should be used for the
transaction context and passed in the serialized
MI. We could make this completely transparent if
we change the MI to implement readObject() and
writeObject(). The writeObject() method could
then call the transaction manager to get the
transaction context for putting on the stream,
and the readObject() method could use an explicit
import() method in the transaction manager to
convert the transaction context into a local
Transaction reference.
A nice sideeffect of this would be that I could
get rid of the collection of transaction frontends
in TxCapsule, and instead have only a single
TransactionImpl instance per transaction.
And the code would be a lot closer to what we
want if we use a "real" distributed transaction
manager. In fact, with a little care I might be
able get so close that neither code changes nor
communications protocol changes are needed when
we change to full transaction distribution.
What do you think?
Best Regards,
Ole Husgaard.
