David Lloyd [
http://community.jboss.org/people/dmlloyd] created the discussion
"Re: Remoting Transport Transaction Inflow Design Discussion"
To view the discussion, visit:
http://community.jboss.org/message/621463#621463
--------------------------------------------------------------
Mark Little wrote:
Some initial thoughts/questions:
a) what do you mean by "unaddressed issues - transaction timeout control"?
I mean that I haven't addressed the issue of transaction timeout control.
Mark Little wrote:
b) since this is distributed transactions (context propagation, commit protocol
termination etc.) have you considered the scope of the testing that needs to be done in
order to ensure this works in *all* cases?
Keeping in mind that this is nowhere near the only process of this complexity to be tested
- and no, don't trot out "it's more complex than you think" unless you
want to enumerate specific cases (which will probably then be appropriated into additional
tests) - I think we'd follow the same approach we'd follow for testing other
things. We'd unit test the protocol of course, and test to ensure that the
implementation matches the specification, and verify that the protocol handlers on either
"end" forward to the proper APIs.
If you're asking "can we write automated tests to prove the validity of the
approach", well no we can't; we're just coding against existing contracts,
and if those are "wrong", well, that fix needs to happen in a different
context.
Mark Little wrote:
c) "any prepared but incomplete transactions have to be recovered manually"?
That's just another way of saying we don't have any special, magical auto-recovery
"stuff" that isn't provided by the transaction coordinator (which might well
have some magical auto-recovery "stuff"). There might be a better way to
express that.
Mark Little wrote:
d) in case 2, where the client is within the same container as a tm instance, which tm is
it trying to control/invoke? The remote one (in the other container instance) or the local
one? Because we seem to have gone from controlling transactions (begin, commit, rollback)
in the first scenario, to really doing distributed transactions in the second scenario. As
you can imagine, these are very different situations.
In case 1, the client has no TM and it uses a remote UserTransaction interface to directly
control the remote TM. In case 2, the client is using the local TM to control
transactions, and is treating the remote TM as an enrolled resource into the current
transaction.
Case 1 cannot be made to work when a local TM is present without adding some notion in the
EE layer to determine whether it should use the local UserTransaction or the remote one.
This is possible but is a possibly significant amount of work.
Mark Little wrote:
e) what about interoposition, particularly in the case where A calls B calls C calls D,
and maybe even D calls A?
Theoretically each successive "step" will treat
the TM of the subsequent "step" as a participating resource. As to D calling A,
that will only work if the TM is clever enough to figure out what's happening (I
don't see why it wouldn't as the Xid should, well, identify the transaction so A
should recognize its own; but that's why we're having this discussion).
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/621463#621463]
Start a new discussion in JBoss Transactions Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]