Hi,
marc fleury wrote:
>
> |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.
Underdesigning a subsystem can be just as bad:
Later on we might have to change interfaces to
implement the full design, and changing interfaces
often implies changing the code that use the
interfaces, and that may introduce new bugs.
In package org.jboss.dtm.rmi.interfaces I have
tried to write a set of interfaces that are very
close to OMG OTS, and that specify all we need for
a full distributed transaction manager. In the
first version we would probably not implement the
SubtransactionAwareResource interface and a lot
of the methods of other interfaces in this package
could be implemented as dummies. By having all
this in the interfaces now we don't have to
change interfaces later on if somebody wants to
add support for nested transactions.
I expect this set of interfaces to interoperate
nicely (and fully) with all DTMs that are based
on (or easily mapped to) X/Open DTM (read: XA),
CORBA OTS or JTS.
> |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?
I guess I should make my objectives on this clear:
I am _not_ particularly interested in implementing
a full-blown DTM for jBoss. I do not see a Java-based
full-blown DTM implemented in less than 50K lines of
code, so this is a big job. But I wouldn't mind at
all if someone wants to do it.
My primary objective here is that jBoss should be
able to use and take advantage of a full-blown DTM.
This could be a jBoss-specific DTM, or any other
DTM. Important here is that we abstract from the
particular DTM used so we do not have to add code
all over jBoss for handling every weird DTM.
So if/when we get this project started, the first
DTM we get in jBoss would probably be an thin
encapsulation of some other DTM. But it would be
able to propagate transaction contexts on all
transports that jBoss supports that are able to
propagate transactions.
> |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...
Well, I don't like it either.
But that is how it is today.
> 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?)
Agreed. Blame JTA for it.
Thread association isn't really needed for transactions
to work, and I'd rather let the container take care of
that.
> |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
Thread local stuff should be up to the container to take
care of. Of course we should still have this mapping in
a JTA TransactionManager for the container to use.
Best Regards,
Ole Husgaard.
