Jonathan Halliday [
http://community.jboss.org/people/jhalliday] created the discussion
"Re: Remoting Transport Transaction Inflow Design Discussion"
To view the discussion, visit:
http://community.jboss.org/message/627593#627593
--------------------------------------------------------------
ok, so I guess we're jumping ahead to the implementation roadmap discussion without
waiting for the EAP6.1 spec then. Is that the same Jason who just got done telling me the
JBossTS planning cycle is too far in advance of the AS planning cycle? :-)
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.
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.
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.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/627593#627593]
Start a new discussion in JBoss Transactions Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]