[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/627612#627612

--------------------------------------------------------------
> Jonathan Halliday wrote:
> 
> If the AS has no preference either way, then I'm inclined to go with the tx branch interposition model rather than full interposition, on the basis that transaction branch lock sharing is a more intuitive and powerful model for users. Whist I think it's the right goal, it's undeniably more complex to implement than the full interposition model. However, rather than go with full interposition as a stopgap and then change over and waste that work, I'd prefer to look at how we can break down the branch interposition implementation into smaller pieces to deliver the functionality incrementally.
Sounds great.


> Jonathan Halliday wrote:
> 
> With an incremental approach we may even be able to put in place a partial solution for some of the more limited but common use cases in AS7.1, much less a later release.  For example, I think it's feasible to extend the org.jboss.tm spi to support a subordinate tx type that exposes beforeCompletion for remote usage. JCA tx inflow does not offer that, but the TS impl under it already does, so we just need the ability to wire it through without tying the AS too closely to the TS implementation classes. That kind of conservative change should be possible on the existing maintenance branch without forking, as it's not going to impact compatibility.  Unifying the way the AS and TS do node identity and putting in place the AS side management of the peer node id list that's needed for recovery can also be done up front to avoid later alteration to the domain model - not all the work is going to be on the TS code side.
To be honest I was already planning on copying the things I liked out of the JBossXATerminator implementation since Remoting inflow for EJBs will obviously not execute in terms of JCA Work objects.  So it sounds like we're aligned on this point at least.  I wasn't sure about beforeCompletion because I didn't see any of that in the code I have, so I'm glad to hear that the underlying API has that.

As for tying AS to the TS implementation, that's not really a problem as that's the whole point of the AS Transactions subsystem.  If and when we need an SPI to abstract around multiple TS implementations, we can probably do that on the AS side.  I'm not aware of any plans on our part to allow other TS implementations though.  I'm not really in favor of SPIs for the sake of SPIs.


> Jonathan Halliday wrote:
> 
> Some of the more involved TS internal recovery changes may also make sense to do even before we know if the wider feature does  make the cut when it comes to prioritizing work for the next release cycle. We could for example potentially enable recovery for multiple resources even in the broken JCA spec semantics, which is an outstanding customer request. It's been a low priority thus far as it's limited to one customer, albeit a large one. But if the work overlaps with wider tx inflow support then it's easier to justify the allocation of resources to it. As the new JCA integration spi is already in place (finally!) the remaining bits needed would likely be entirely arjuna internal, so again probably doesn't require a major version rev or fork on the TS code side.
> 
> Whilst getting at least some functionality out sooner rather than later is probably a good thing, one of my concerns on delivering this in staged releases, potentially including the current cycle, is the impact it will have on docs and QE. We'd need to clearly specify what scenarios are expected to work in each release we provide, in order to test correctly and manage user expectations thoroughly. We probably need an internal discussion with those teams to see what resource they have available in addition to seeing what dev resource we can shake loose for this by deprioritizing other things.
Well before we get ahead of ourselves and drown in borrowed trouble, it might be better to identify what specific tasks need to be accomplished, and by whom.  Once we have a clear sense of what needs to be done, then we can figure out how we want the releases to go and what resources should be dedicated to what.

In particular I still only have a general sense of what is involved in the branch interposition model - to be specific, it's not clear what the transport requirements would be for negotiating the XID space; you mentioned alternate XID formats as well as bitmask-based solutions, but none of this is really specific.  And I don't have a clear understanding of what issues we'll face in terms of recovery - though perhaps I don't need to, as long as it is clear what the transport requirements would be for this as well.  By "transport requirements" I just mean, what communication steps will the coordinators need to perform in order to accomplish the tasks which make up propagation and recovery.

Also it's not clear to me how XIDs can actually be created, which I imagine will follow directly from the solution we decide on for how the bqual is selected.  It seems like once this is figured out, the rest of the actual inflow code should be pretty straightforward.

So how should we break down the task list?  Off the cuff we have:

* Design the XID negotiation/generation scheme (conceptual work, no coding)
* Implement the XID negotiation/generation scheme (possibly split between AS-side and TS-side)
* Design the XA inflow scheme (conceptual)
* Implement XA inflow (probably mostly AS-side, once the XID stuff is in place)
* Design the recovery scheme (conceptual)
* Implement the recovery transport mechanism (mostly AS-side)

For the design points, I think we should probably split each into a forum thread, but honestly I think you TS folks should take the lead on these since you have the experience.  I'll jump into the implementation parts as soon as the design is clear enough.

Thoughts?
--------------------------------------------------------------

Reply to this message by going to Community
[http://community.jboss.org/message/627612#627612]

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/20110920/e266f268/attachment.html