Mark Little [
http://community.jboss.org/people/marklittle] created the discussion
"Re: Remoting Transport Transaction Inflow Design Discussion"
To view the discussion, visit:
http://community.jboss.org/message/621637#621637
--------------------------------------------------------------
"A->B->C yes is possible, however this is really (A client -> B server ->
(a bunch of existing stuff) -> B client -> C server); which is to say that if we
verify that we follow the rules for what we implement, then it's up to JBTS to follow
the rules for what +it+implements."
How do you expect to prevent the context from flowing from B server to B client? A
per-thread interceptor doing the disassociation, for instance?
"Well, all of this is predicated on the assumption that we still need some kind of
remote control of transactions from server to server when using the Remoting-based
transport in order to fulfill our obligations for existing functionality. If we can work
it out or establish that this is not the case, then sure, we can revisit this discussion
at a later time, assuming that such time would ever arrive. I would very much like the
opportunity to be able to work on establishing requirements for such an abstraction. Such
a discussion should come hand in hand with fixing the shortcomings of XATerminator in the
JCA specification as well though, as these seem to me to be two faces of the same
problem."
Whatever happens now, I think it's clear that we need to look at this for the future.
And a realistic future at that, i.e., not "years and years from now".
"I don't think I said it wasn't possible, or at least I didn't intend
to. I think supporting trees or linear chains of appservers is fine. I just don't
think we necessarily have to support A->B->A kinds of scenarios or other non-tree
(especially cyclic) directed graphs as this is not generally a good fit for Remoting in
the first place; one would normally choose IIOP or JRMP for this kind of topology."
OK, but this then comes back to my first question above: how do we prevent these things?
Leaving it up to the developer of the application/business object/EJB isn't going to
work.
"That said, I think that a proper implementation ought to be able to mix and match
the approaches. A linear chain of app servers and their resources using the Remoting
transaction approach could terminate an a JTS "cloud" of appservers, which in
turn could enroll more linear chains of app servers and their resources, so long as the
contstraints we place aren't broken (for example if we don't support shared
resources in the Remoting chains then we simply don't)."
Agreed, and in fact this sounds very much like the genesis of the bridging work that I
keep mentioning Jonathan has been doing (has done). The idea there was that a transaction
could start out over, say, SOAP, inflow to a container and then be sent out over another
transport, etc. Graphs of arbitrary size and complexity could be supported, with
extensibility to support arbitrary transports.
"Could we drop a native transport in favor of SOAP+IIOP? Absolutely. But it would
suck, IMO. I think a native transport is an essential tool, and it's something
we've provided in the past, but it's not up to me to make that call in any case.
Even if we dropped it though, I'd probably develop it in my free time anyway just
because I have no inclination to use SOAP or IIOP for my personal projects, and it's
something I believe in. Granted my free time projects have this way of winding up back in
the middle of things these days."
Yes, I understand the trade-offs. I mentioned it in order to determine if there was some
intermediate step(s) that we could take to help address the issue.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/621637#621637]
Start a new discussion in JBoss Transactions Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]