Hi,
marc fleury wrote:
> |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 wouldn't design by it, but it is another exception
that we might have to deal with if we don't do something
else. So please read this as just another argument in
favor of doing something else.
> |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 :(((
The XA legacy has always been the base of our TX
design: JTA is based on XA.
Encapsulating the Xid in a TransactionImpl object
doesn't really change that: What matters is the
Xid (or more precisely: The transaction id), and
the TransactionImpl in the MI is IMHO just a
complication.
> |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.
No. I'm not talking about associating the transaction
with a thread here. That should be not done when
getting the Transaction from the MI. Thread association
should be done at the container's discretion.
What I am talking about here is the import of the
transaction into the TM. When someone invokes
MI.getTransaction() it indicates an interest that
the transaction should be used in the local VM. So
an import will be needed, so why not just do the
import on the first call to MI.getTransaction().
This way we do not have to worry about having a
Transaction instance that might not have been
imported.
> |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
I think we agree (se above).
It is important to note that the assocation of
transactions to threads isn't really needed for
transactions to work. It is merely a convenience
function so that transaction users do not have to
explicitly pass Transaction references as extra
arguments in all method calls.
Only the transaction import (which is orthogonal
to the thread association) is needed before
the transaction can be used.
> |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
Yes. I wanted to avoid touching code in other
packages I didn't fully understand.
But now I think I start to understand...
> |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 agree that the thread association should be up to
the container. But transaction import and transaction
export are closely tied to the transport used and
might better be transparent to the container.
> I will say this, the TM was done was done in 4 hours, and it just meant as a
> fast IN VM TM...
Wow. Only 4 hours. You are very productive. It would
probably have taken me at least two days.
I like this fast in-VM TM, and don't think it should
be touched or removed even if we get a full DTM.
But I would like the interface to the in-VM TM to be
so close to the interface of a full-blown DTM that no
container code should be changed if/when someone comes
up with such a beast. And I think that we are very
very close. Only thing I see missing is better handling
of transaction import and export, and this should really
be done in cooperation with the transport.
For the RMI transport of transaction contexts, I think
that we could also get so close that no code changes would
be needed. For this to be the case we should not pass
a Transaction or a Xid in the MI, rather we should use
a transaction propagation context object similar to the
org.jboss.dtm.rmi.interfaces.PropagationContext. Here most
fields would be null for the in-VM transaction contexts.
An (IMHO big) advantage of this would be that the transport
protocol is the same for in-VM and full DTM. This means
that client updates would not be needed when switching
to a full DTM. It also means that people who run a
federation of servers would not have to update all servers
at the same time when they switch over to a full DTM.
> 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???
Going to answer that old DTM mail from you now...
Best Regards,
Ole Husgaard.
