[jboss-dev-forums] [JBoss Transactions Development] - Re: Remoting Transport Transaction Inflow Design Discussion

[David Lloyd]

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&containerType=14&container=2041]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-dev-forums/attachments/20110817/de5c1c19/attachment.html