JBossDeveloper

per-resource, if only because isSameRM is broken in weird and wonderful ways on many drivers. My fav is the one that does string comparison on the connection url, so can't cope with e.g. hostname aliases...

So to summarise the idea is that before 2PC but after all "xa_end" calls are made we ask the resources if they want to be called "first". In theory the ones that assume they will be RDONLY will respond yes, the others would respond "no" (or "yes" if they want to be mean and scupper the optimization)?

Did I parse this right?

yes I think that's right as far as David's requirements are concerned. The DB vs JMS ordering problem that gave rise to JTA-4 is more difficult, since it needs to distinguish between a XA_OK JMS and and XA_OK DB, both of which would respond 'no'. We may need e.g. the return type to be a structure with additional data that the JTA can use when ordering them, or to establish some conventions e.g. an enum with defined ordering or a number range with some defined constants.

As far as the patch goes, I'd be inclined to do it in two passes: the groundwork to refactor the lifecycle so arjunacore drives xa end as a separate phase; then the ordering stuff. The first of those parts could go in now, though it would not be immediately useful. The second needs us to pin down the ordering API and semantics, with or without input from the spec process.

Thanks Jonathan, ochaloup - does that work for you too?

I agree it might need some further ordering encoding in there (maybe a class name or numeric order as we have discussed before I expect). If Ondra does a refactor of the xa_end now and also extends the design doc he has shared with some ideas on the ordering options. We can then go to the spec committee with the concept but also have a proof of concept (for EJB only until we determine if it will go into spec, so keep in an .internal. package for now).

Unless it is a problem I would think it best that normal XA rules for the resources. This would just guarantee you could order the ones that are going to return RDONLY to be called first.

A small point is that 2PC should not (IMO) halt if you can't xa_commit an nth resource.

i.e
// ask resources for their order NEW PHASES
// xa_prepare in order (assume they are all XA_OK, so not really using the new feature
// Go into commit
xa_commit(1)
xa_commit(2)
xa_commit(3) // comm failure
still:
xa_commit(4)

If we were being strict we should probably not do xa_commit(4) until xa_commit(3) was sucessful I expect. We could make strict ordering an option but it is better as a hint I think.

> would the TM be able to use its isSameRM knowledge in order to know that it's a 1PC even if multiple (isSameRM) resources return XA_OK

The spec doesn't really allow it to. It calls the resource operations once per branch (i.e. XAResource instance) not once per RM, because the state machine is defined per-branch, not per-RM. It's theoretically possible for an RM to return OK from one branch but ROLLBACK from another, for example if the work in one branch's scope caused a conflict and the other didn't. Likewise in phase two a branch can throw a heuristic whilst its sibling in the same RM doesn't. The optimization has to come from the RM side.

I'd envisaged a XAResource.getOrderingHint() to have regular getter semantics - it's a read-only method on the object that should return the same thing if called multiple times. It's categorically not a state change operation like end or prepare. Best implementation guess, the xa_end (or the first hint call, if lazy) sets some internal state in the resource that the ordering hint refers to. Whilst in normal operation the TM should indeed only need to call it once, I don't really like the idea of a getter that will blow up if invoked multiple times. We'd probably want to rename it to reflect that if it's necessary. Are you implying it's tricky to implement in way that allows multiple calls?

hmm. When are they getting serialized? Is that for the client-server transport, or for the transaction log? There is a narrow window of time in which it's valid for the TM to invoke getOrderingHint - specifically between all resources being ended and the first being prepared/committed. Outside of that it could reasonably e.g. throw IllegalStateException.  You'd need state for the optimization anyhow, since you'd need to track which one is returning OK whilst the others do the RDONLY trick?

I'm not hugely worried about preserving idempotent behavior across serialization boundaries, since it's not likely to be used anyhow. I think it's reasonable to just cop out with an IllegalStateException or e.g. return Hint.NO_PREFERENCE in that case. I'm more concerned that having a non-idempotent getter violates the 'no surprise' rule for API design on the in-memory object instance. As far as possible it should be stable if the resource state doesn't change. It can (and should) change return value if the actual prepare result doesn't match the previously hinted one. The ordering hint is a suggestion, not a firm promise. The TM may ignore it, or the RM may get it wrong or not provide it. Best-effort will suffice - in harder cases we just fall back to the unoptimized order.

To my mind it's the choice of initial value that's tricky, rather than remembering/repeating it once it's decided. That's because although each branch (resource instance) has its own xa state machine, the underlying implementation is really one state machine per-tx, shared by all branches. The optimization with N-1 RDONLY + 1 OK branch in the same RM is essentially a case of having N-1 of the per-resource state machines working as stubs, whilst the other passes through to the real transaction state machine. At some point you need to choose which resource is the special case, then get the others to behave accordingly. So the state underpinning the hint is not strictly local to the resource instance, but the result of a collective decision across all the resources for the RM. The hint value may therefore change, even though the resource state (at least in terms of the xa state machine lifecycle) doesn't. That's why I think it may better to just throw an exception if invoked too early i.e. whilst other branches of the tx for which isSameRM==true are still not ended.