[jason.greene]

I've been traveling most of the day and I am cutting an AS release and working on a presentation for a JBUG I need to do in a couple hours, so I don't have much time to comment a more detailed reply to the topic (sorry!).

Breifly, I just wanted to mention that my primary concern was having a solution in ANY EAP6 release. To me this was an escalated AS + TS integration problem that everyone agreed needed to be fixed, so whatever stop gaps we go with need to be short lived, and 2 years is just too long to have this issue. I realize that getting this into EAP 6.0 was a big stretch, but the work should be able to start now, and as I mentioned in the past fixing EAP6 integration issues is more important than any EAP7 feature. I definitely want to avoid doing a one off patched fork, but after hearing that no changes are allowed to happen in the only release branch that is compatible with EAP6, that appeared to be the only option. We do have resource constraints for 6.0, but 6.1 we have breathing room so can "make things happen".

I promise to explain in more detail later, but hopeful that clears up my position somewhat.

Thanks.

[marklittle]

Yes, slightly. I think there was a misunderstanding between parties then at least as timing goes, because the TS team were alreadly planning for 6.1. I suspect that the recent comments also gave credence to the fact that there was a push to get something, no matter what, into 6.0. Good to hear that that is clarified now on both sides, because as we keep hearing these changes are going to require a lot of testing and input from others. My biggest concern has always been pushing something into the release that's not fully tested.

[tomjenkinson]

Hi Jason,

Thanks for the clarifying the timescales involved. Certainly 6.1 is a comfortable position to aim this functionality at and I for one have breathed a sigh of relief

As soon as we agree a clear picture of what the functionality looks like we should raise a Jira for this in the JBTM project so we can track the functionality's progress.

Tom

[jason.greene]

Mark Little wrote:

Yes, slightly. I think there was a misunderstanding between parties then at least as timing goes, because the TS team were alreadly planning for 6.1.

That's fantastic news then. My comment was in reaction to an email from Jonathan that all new work most go into TS 5, which would be incompatible with 6.0 (and also that the planning cycle for 5 is basically over). So I can take this to mean there will definitely be a 4.16 which will address discovered EAP 6.x issues such as this?

My biggest concern has always been pushing something into the release that's not fully tested.

Yeah I certainly understand the concern here but to a certain extent we have to pick a lesser evil. My understanding (feel free to correct), is that XATerminator when used with 4.15 may be unable to enlist more than one resource without detrimental side effects. It does seem though that even with 4.15 there are some pretty powerful SPIs we might be able to use for a stop-gap solution (perhaps some kind of bqual xid manipulation can be done there?) This does make me wonder, that even conceeding the API is inadequate, what other XATerminator implementations do to handle this issue.

[jason.greene]

Mark Little wrote:

I suspect that the recent comments also gave credence to the fact that there was a push to get something, no matter what, into 6.0.

Just to clarify my position is

1. We need a decent stop-gap for EAP 6.0, whatever that may be

2. We need the real solution in EAP 6.1

The fork comment wasn't emotive, it was a practical reality. If the TX project was not going to do a 4 release that fixed the problem, then soemone else would have to. It's essentially the same way we handle a thirdparty project (e.g. apache) that does not share our schedule.

[jason.greene]

Jonathan Halliday wrote:

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? :-)

Yep, and I think I have been entirely consistent on this front. I may not have communicated clearly but maybe it helps to understand my motivation. I want EAP 6.0 to be the best apppserver on the planet! Everything I say is in connection with that. The planning too far in advance position comment was about the practice of locking down a TS release (in this case we are talking 4.x being locked down in April) and being unflexible to changes which impact the quality of the current in progress EAP release (EAP 6). In other words, to me the ends nearly always justify the means.

[tomjenkinson]

Jason Greene wrote:

I want EAP 6.0 to be the best apppserver on the planet!

+1

I do believe there has been some misinterpretation in regards the content of the thread. We are very happy to add this feature into 6.1 and work with you to provide an intermediate solution for 6. The main concern we have is terms of the intermediate solution is about ensuring we deliver a quality supportable component (i.e. QE/docs) in the timescale available.

Perhaps now though is the time to move on to the more exciting part, designing this feature work and seeing what can realistically make it into 6 vs 6.1?

[dmlloyd]

Right, the part of this thread where we talk about who said what and timelines and management and resources and positions is over.  I want every subsequent post on this topic to be 100% technical!  Time to put the money where the mouths are.  I'd like to see the individual design topics kicked off ASAP; it's time to move forward.

[tomjenkinson]

Hi,

Just to keep you all in the loop I have now created https://issues.jboss.org/browse/JBTM-895 to track this work more formally. I have raised it as Blocker on 4.15.x and have personally assigned it to myself. By all means we can keep discussions going in here but at a suitable point it would be worth (perhaps when we have more than  "more details coming soon" in the description of the Jira) we can transition discussion to this Jira.

Jason and David, I have added you as watchers on this Jira, feel free to become Voters too on it but as you know, we are working on this already

I will spend the rest of today, this weekend and Monday fleshing out the description of the Jira with what we have so far.

Tom

[marklittle]

Understood, but TS is not a 3rd party project and we shouldn't be in a situation where it's even necessary to consider it as such.

Jason Greene wrote:

Mark Little wrote:

I suspect that the recent comments also gave credence to the fact that there was a push to get something, no matter what, into 6.0.

Just to clarify my position is

1. We need a decent stop-gap for EAP 6.0, whatever that may be

2. We need the real solution in EAP 6.1

The fork comment wasn't emotive, it was a practical reality. If the TX project was not going to do a 4 release that fixed the problem, then soemone else would have to. It's essentially the same way we handle a thirdparty project (e.g. apache) that does not share our schedule.

[marklittle]

And created design discussion entries in the forums too please

Tom Jenkinson wrote:

Hi,

Just to keep you all in the loop I have now created https://issues.jboss.org/browse/JBTM-895 to track this work more formally. I have raised it as Blocker on 4.15.x and have personally assigned it to myself. By all means we can keep discussions going in here but at a suitable point it would be worth (perhaps when we have more than  "more details coming soon" in the description of the Jira) we can transition discussion to this Jira.

Jason and David, I have added you as watchers on this Jira, feel free to become Voters too on it but as you know, we are working on this already

I will spend the rest of today, this weekend and Monday fleshing out the description of the Jira with what we have so far.

Tom

[tomjenkinson]

We have one happening live right now over: http://community.jboss.org/message/629306

It has UML and everything

[tomjenkinson]

How does this look as an interface to drive the required behaviour?

I would assume you would acquire a singleton instance of this through a getter on the impl, e.g.

JTADistributionManager manager = JTADistributionsManagerImpl.getJTADistributionManager()

public interface JTADistributionManager {

     // TRANSACTION ASSOCIATION MANAGEMENT

     void start(Xid xid, long timeout) // This should be the absolute time you want the transaction to timeout

     void resume(Xid xid) // TO BE CALLED WHEN YOU WANT TO RESUME THE TRANSACTION AT THIS NODE

     void suspend(Xid xid)  // TO BE CALLED WHEN YOU WANT TO SUSPEND THE TRANSACTION AT THIS NODE

     /// TRANSACTION LIFECYCLE MANAGEMENT

     int prepare(Xid xid) throws XAException;

     void commit(Xid xid) throws XAException;

     void rollback(Xid xid) throws XAException;

     void forget(Xid xid)

     Xid[] recover(int flag)

     // SYNCHRONIZATION CONTROL

     void beforeCompletion(Xid xid);

     void afterCompletion(Xid xid, int status);

}

NOTES:

Regarding the timeout, I figured the transport would converted this to an absolute time? I can only really see it working with an absolute time and clocks in sync, then when we add it to the reaper we can calculate the remaining time. I am interested to know in the original question some of Davids concerns regarding timeout.

Assumptions:

1. Every time remoting invokes a remote application server it must do the following two things:

a. If not already done so, create a proxy Synchronization object and register it with the transaction - distributed JTA interposed synchronizations are not supported in the initial version. This will invoke the beforeCompletion and afterCompletion methods on the remote JTADistributionManager

b. f not already done so, create a proxy XAResource object and register it with the transaction, this is responsible for sending the subordinate transaction managers transaction lifecycle messages prepare, commit, rollback, forget, recover, setTransactionTimeout

c. On the remote side, it needs to call either start/resume dependent on whether remoting detects it has sent the transaction to this server before

d. After remoting detects the interaction is complete, it can call end on the JTADistributionManager

2. As we have no way to communicate back up the tree, I have assumed that only the originating client can initiate completion of a transaction, this is consistent with the JTA spec 3.2.2 but will need documenting

3. In the case of failure afterCompletion may not be called

As yet unresolved is how to modify the Xid correctly in order that local recovery managers detect the indoubt transactions, watch this space, but this is being tackled, David mentioned an approach on the Synchronizations thread that may assist: http://community.jboss.org/thread/172869?tstart=0

If you are happy with the proposed interface I will update: https://issues.jboss.org/browse/JBTM-895

[marklittle]

Let's create a new topic for this now :-)

[marklittle]

For distributed timeouts check out what we do with the JTS.

Tom Jenkinson wrote:

NOTES:

Regarding the timeout, I figured the transport would converted this to an absolute time? I can only really see it working with an absolute time and clocks in sync, then when we add it to the reaper we can calculate the remaining time. I am interested to know in the original question some of Davids concerns regarding timeout.