|If we should implement a fully distributed transaction
|manager as part of jBoss, I think we should support
|multiple protocols and be able to import transactions
|from all of these (on incoming calls) and export
|transactions to all of these (on outgoing calls).
sure but don't overdesign, works well with one is better than doesn't work
well with various implementations.
|As for package structure:
|I would prefer to let the DTM have its own package
|org.jboss.dtm, so that we do not touch the current
|transaction manager.
yes let's start a new package and sub-project.
Any name you guys want?
|Under this package we could have packages for the
|various protocols: org.jboss.dtm.rmi for the RMI
|interface and implementation, and iiop for the IIOP
|implementation. In the tarball I've placed the RMI
right :)
|interfaces in package org.jboss.dtm.rmi.interfaces,
|and expect the RMI server code to be in
|org.jboss.dtm.rmi.server.
|
|Transaction propagation in the current TM package is
|implicit: Import happens automatically when a thread
|is associated with a TransactionImpl representing a
|transaction that has not yet been imported. And export
|happens simply by serializing a TransactionImpl
|instance.
OK this I am totally against... don't do it...
the implicit propagation of the transaction (by thread local) is an
aberation in the web world. We only need to associate when we need to and
in fact we should not rely on any thread associated information since it
relies heavily on the proper management of these associations and it is all
over the map. Don't do it. I have much rather work from the Tx associated
with the "invocation message" that is our MethodINvocation class.
You need the equivalent of the Jonas "get/setPropagationContext" and that is
the way it is done rigth now in the TM... threads on the web are just
"tools" they have no real personality and associating "instance specific"
stuff is only needed when the API doesn't carry the information (when we
call a bean for example, but that is all)
We use it for implicit propagation at call time, but that is all and it is
fairly limited in scope. The main reason is that it is slow (thread local
map lookup) and hard to debug (where did this thread come from? how come
there is something associated with it when there should be nothing?)
|But when we support multiple protocols each having
|their own transaction propagation context type, things
|are not that simple. Doing more explicit import and
|export is probably needed.
|To show how this could be done, I have written the
|interface to a class org.jboss.dtm.TxManager with
|two methods for each protocol: One for getting a
|transaction propagation context for the protocol and
|one for importing a transaction propagation context
|for the protocol into the transaction manager.
right on
|
|This is just suggestions, and thus I have comitted
|nothing yet.
|Comments and constructive critique is welcome.
ok :) on the good track... as little implicit thread local stuff in the run
time (only when calling beans) is the way it is done
marc
|
|
|Best Regards,
|
|Ole Husgaard.
|
|
