|> 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 still don't like them, they are slow and if you can avoid them, do so.
But in some cases we have to (like a call to the instance)
|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.
true at least of JOnAS... actually I made it this way on purpose, just to
keep it simple
|deserialization. But the Transaction instance we
|get from deserialization is really useless unless
|imported locally. In the first versions of the
well that is true of most tx implementations, you need a
"setPropagationContext" to import a transaction.
|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.
Not following the first version relied on such an association, but
whatever...
|This works only because the TransactionImpl is
|serializable and holds a reference to the Xid,
|and because the XidImpl is serializable.
sure
|But now Aaron has added support for using other
|Xid implementations than XidImpl, as this is
|needed for Oracle XA drivver interoperability.
ok
|This means that we risk having a non-serializable
|Xid reference in our TransactionImpl.
no design by exception :)))
|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
sure that is ok, we have now made the XA legacy the base of our design :(((
|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,
No that I don't agree, the readObject should not take the decision to go and
associate with the TM, it is up to the various interceptors to associate or
not, this is one of the reasons I like to pass a TxImpl around.
|and the readObject() method could use an explicit
|import() method in the transaction manager to
|convert the transaction context into a local
|Transaction reference.
no, I have little problem with passing Xid XA legacy as identifier but
unfortunately the association decision is somewhere else
|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.
true, but... it was your decision to follow them ;-) I didn't
|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?
that passing around xid is ok, but the association is up to the container.
Don't "import" in your corner, implicit passing is the bane of OO
programming (a necessary evil).
I will say this, the TM was done was done in 4 hours, and it just meant as a
fast IN VM TM... making something else means a full distributed TM that in
my mind is a separate project...
do you have a name for that sub-project???
marc
|
|
|Best Regards,
|
|Ole Husgaard.
|
|
