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&...]