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/621460#621460
--------------------------------------------------------------
Jonathan Halliday wrote:
re: ( 1 ) Whilst the remote UserTransaction model is easy to implement, it's tricky
to document. It behaves in an intuitive fashion only for a very limited, albeit common,
set of use cases. For more complex scenarios its inherent limitations manifest in ways
that can be confusing to users. The cost of this solution must be evaluated not just in
terms of implementation time, but in documentation and ongoing support cost.
re: ( 2 ) JCA inflow was either designed for propagation to leaf nodes only, or
incredibly badly thought out. Either way, the result is a model that simply isn't
capable enough for a full distributed transaction solution. So, once again you're
going to wind up with unintuitive behaviour and limitations for some use cases. For
example, you can't register more than one resource with an inflowed transaction, you
can't allow a context to be flowed into a node by more than one route and you need to
register each subordinate node in the parent for recovery purposes. So, whilst this may
provide a faster alternative to RMI/IIOP for simple use cases, it's not going to be an
acceptable substitute for more advanced cases. Offering it alongside the traditional
RMI/IIOP model is going to have implications beyond just the initial engineering, so the
discussion may require input from docs, support and QE too. I'm pretty sure that e.g.
support will tell you it is unacceptable to ship a solution that may require manual
transaction cleanup. We've had a small number of corner cases in JTA that suffered
that limitation and eliminating them and the support load they generate has been a high
priority for the transaction development work. Intentionally introducing new ones is
definitely in the category of Bad Ideas.
Rather than flinging FUD at the only two possible approaches that are available to us, can
you be more specific than "Bad Idea" or "some complex scenarios" or
"badly thought out" or "not capable enough" or "unintuitive
behavior" or "limitations" or "not acceptable substitute"? This
really is not productive. Better still, explain specific issues in specific scenarios
that apply to each approach, and why that issue is valid under the Remoting client/server
architecture?
Also - only one resource for inflowed transactions? How is that not a serious deficiency
in our implementation? You're basically saying that an MDB can never access more than
one resource. That's a major problem in and of itself.
Finally "unacceptable to ship a solution that may require manual transaction
cleanup" - you should know that any two-phase transaction system may require manual
transaction cleanup; that's the nature of two-phase transactions. You'll have to
be more specific about the circumstances in which it is not acceptable to require manual
cleanup. I'm pretty sure that if someone unplugs the ethernet cable of the
transaction coordinator after prepare but before commit, there's going to have to be
some manual cleanup.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/621460#621460]
Start a new discussion in JBoss Transactions Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]