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).