minutes from the afternoon of 30th June 2005

[Mark Little <Mark.Little@arjuna.com>]

Here are the minutes from the JavaOne face-to-face: 30th June, afternoon.

Discussion around a WS-CF interoperability demonstrator. Greg said that Oracle 
wanted to wait for WS-ACID before doing further interoperability because we 
would have to invent a protocol for WS-CF anyway. Martin said that he would 
prefer to have a stand-alone WS-CF demonstrator. Everyone agreed that if that 
route were taken, it would have to be a coordination protocol that was fairly 
simple, to avoid spending a lot of time and effort on it.

Kevin said that he had sent an email some time ago around this subject, but 
was not sure about the detail. Greg and Eric agreed that it was a good 
approach but could not commit resources yet - need to see details.

ACTION: Kevin to come up with a proposal for a stand-alone WS-CF 
interoperability demonstrator.

End of business for WS-CF and WS-Context. Martin suggested going through the 
existing WS-ACID issues before tackling the specification. Mark said that we 
need to remember that most of the issues date back to when the TC formed and 
may no longer be relevant.

Issue 29 - CLOSED as irrelevant now.
Issue 31 - need to address
Issue 34 - editorial typo
Issue 35 - editorial typo
Issue 36 - editorial consistency issue
Issue 37 - terminology
Issue 38 - editorial
Issue 39 - editorial
Issue 40 - editorial typo
Issue 55 - normative discussion
Issue 56 - normative discussion
Issue 57 - normative discussion
Issue 58 - editorial

Greg asked if we want to change the name of the specification. Is WS-ACID too 
strong? Greg made it clear that he had no strong feeling either way, only that 
maybe the two-phase commit component could be used elsewhere.

Martin suggested WS-AtomicCoordination.

Mark said that the important thing about WS-ACID was that users/developers 
knew the semantics of the interactions and that assisted in its 
interoperability requirement. Greg and Martin agreed.

Mark suggested that there were two possible routes to maintaining this aspect 
that he could see:

(i) keep with the status quo

(ii) have a specification that provided only atomic outcome (factor out 
Synchronization) and provide the CID via policies.

Eric said that interoperability with existing TP systems is the most important 
use case. It is the whole point of the protocol and it's where IONA are seeing 
client pull. Everyone agreed.

Eric suggested that relaxation of the properties as Greg suggested is a 
different use case.

General discussion ensued and it was agreed that this would be more than just 
a name change if pursued. Decision taken to leave as is for now. Issue 268.

Mark added an issue (269) to ensure that WS-ACID boiler plate is consistent 
with other specifications.

ACTION: editors to remove all outstanding references to ALS and anything else 
removed from WS-Context or WS-CF. Issue 270.

Mark said that he thought there were no major problems with WS-ACID since it 
is just traditional TP. The WSDL/schema are out-of-date and need fixing (Issue 
271), but editorial work was probably the biggest task left.

Do we want to change the protocol names from two-phase commit and 
synchronization to something else? Everyone agreed they were good.

Mark: we need to bring the faults up-to-date with the new fault model in 
WS-Context/WS-CF. Issue 272.

There was discussion about the fact that unsolicited responses are explicitly 
allowed in WS-ACID, but the mechanism uses the setResponse operation of WS-CF 
which has now been removed. However, because the interaction pattern is based 
on one-way messages, we can still support this pattern.

Greg asked if we could explicitly specify when unsolicited responses are 
required. It was agreed that the operations were only RolledBack and Prepared.

Eric wanted to make sure that it was optional because some implementations may 
not be able to support it.

Greg wondered if this might affect interoperability, but Mark said he did not 
think so because even if it is supported, timing conditions may mean that an 
unsolicited response is sent just as the actual request is being generated: 
the participant (in this case) would have to be able to deal with that 
situation anyway. Idempotent.

Eric then asked if we should remove the one-phase commit optimisation because 
in traditional transaction processing systems having a single resource in a 
transaction typically doesn't require interaction with a coordinator at all. 
There was discussion around this and it was agreed that one-phase commit is 
required in a distributed environment when the transaction can span multiple 
machines and a priori knowledge of the participants isn't known.

Change of text associated with one-phase commit: If the coordinator discovers 
that only a single participant is registered then it SHOULD ommit the prepare 
phase.

There was discussion about whether we should support heuristics. It was agreed 
that we definitely should.

Eric wondered if we should add support for isolation levels, particularly 
since most databases permit it. Serializable, read committed ...

Mark asked if this would be via a policy?

Eric said that would be one possibility. A default of assuming serializable.

Greg said that not all resource managers support serializable because of the 
overhead. General discussion; do we go with policy or leave as is (for 
example, the OTS does not define isolation levels).

Eric said that he preferred a policy so that it MAY be determined.

Greg said that this should be purely declarative. Make a statement about the 
characteristics of the service to do with isolation and ensure it is 
composable with any policy language.

Martin said that this should be expressed through a policy based language.

ACTION: to agree on some text to address this Issue 273.

Martin asked for the entire WS-ACID hierarchy to be described, including 
context and coordination. Eric gave an overall presentation.

One issue arose as a result: there is no way to commit or rollback the 
transaction directly at the level of WS-ACID. It is tied to the termination of 
the underlying activity and hence the WS-Context complete message. This 
message allows for a status extension value to be passed, which should be 
interpreted by a coordinator as "roll back" or "commit". Editors to make sure 
that the text in the specification is clear on this. Issue 274.