|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.
I am not sure I understand what you mean by "import", can you be more
precise in "before/after" terms.
|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.
yes
|Only the transaction import (which is orthogonal
|to the thread association) is needed before
|the transaction can be used.
again please explain, do you mean wired to the Transaction Manager? what do
you understand by "wired", if is the "tracking" of the Tx by the TM, again
remember that is a "feature" you introduced recently... the original
"4hours" design was meant as a light and super fast implementation...
keeping track of all the public faces is expensive imho.
|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.
ok explain transaction "import" since it is standalone, the ID of the
transaction is sufficient to "do work" with it... I don't need an extra step
for "import" in the current inVM implementation, even after travelling.
Please be explicit as to what the "import" buys us in your mind that is not
already there.
|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
agreed,
|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.
ok be explicit, show you are onto something...
|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.
We pass a Tx, if you want to pass a "context" that is fine, that is the way
jboss1.0 worked... again I guess it depends on what we put in our "TxImpl"
and again the current one works simply and fast inVM, building one that
works DTM is not that complicated (pass a Remote one and build optimizations
in, ala proxy currently)...
I am not religious in interfaces and names, as you know I believe in
iterative design. One thing I don't believe in is complicating things with
20 classes and inheritence for the sake of "object design" that imho is
bull... show me an advantage for your DTM/standalone and you have my
blessings.
Make it work, it the most important thing in my eyes... that's the only real
beauty.
marc
|
|> 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.
|
|
