Is there one-phase commit in WS-AT?

[ivanneto]

Hi!

The WS-AT specs v1.0 and v.1.1 do not explicitly discuss the one-phase commit (1PC) optimization. However, the WS-Transaction spec from 2002 does discuss 1PC. The XTS Programmer's Guide also discuss 1PC (on page 27):

If a transaction involves only a single participant, WS-Atomic Transaction supports a one-phase commit optimization. Since there is only one participant, its decisions implicitly reach consensus, and so the coordinator need not drive the transaction through both phases. In the optimized case, the participant will simply be told to commit and the transaction coordinator need not record information about the decision since the outcome of the transaction is solely down to that single participant.

Is there 1PC in WS-AT? If there is, then the transaction coordinator just tells the participant to commit, without sending a prepare message before? Again, if there is 1PC, then in a multi-vendor environment, all WS-AT-compliant implementations must support 1PC, right?

Regards,
Ivan

[jhalliday]

The docs are wrong. WS-AT 1.0, which is what the current version of XTS supports, does not allow for one-phase commit.

[marklittle]

WS-AT does not support the one-phase commit optimization (the XTS docs are wrong). WS-ACID (from WS-CAF) did/does.

[ivanneto]

Thank you Jonathan and Mark!

Two doubts I have in my mind right now:

1) Any ideas why WS-AT does not support 1PC? I have no idea why it was removed from the 1.0 spec.

2) Why does the WS-AT coordination context use an URI as the transaction identifier? Why not a xid like OTS? I see that a xid would not make sense for WS-Coordination, but I think that WS-AT should standardize a way of propagating a xid. Shouldn't it?

Regards,
Ivan

[marklittle]

"ivanneto" wrote:
Thank you Jonathan and Mark!

Two doubts I have in my mind right now:

1) Any ideas why WS-AT does not support 1PC? I have no idea why it was removed from the 1.0 spec.

It's a long story, but suffice it to say that it's a mixture of political and technical reasons. When working in a standards organization you've sometimes you can't always get agreement. You ever heard that a camel is a horse designed by committee ;-)?

2) Why does the WS-AT coordination context use an URI as the transaction identifier? Why not a xid like OTS? I see that a xid would not make sense for WS-Coordination, but I think that WS-AT should standardize a way of propagating a xid. Shouldn't it?

Well OTS didn't really standarize on an xid: just the structure.

struct otid_t
{
 long formatID; /*format identifier. 0 is OSI TP */
 long bqual_length;
 sequence <octet> tid;
};

Even here we have a lot of scope for different formats. URI makes perfect sense in the Web and for transactions, because after all you just need to make sure the txid is unique. If you're importing from a foreign transaction manager then the particiapant or subordinate will have to perform a mapping, similar to JCA for example.

All of the Web Services specifications I've worked on since 1999 have used a URI for the txid. It hasn't caused any problems that I'm aware of. If you've got concerns I'd be interested in hearing them.

[ivanneto]

Even here we have a lot of scope for different formats. URI makes perfect sense in the Web and for transactions, because after all you just need to make sure the txid is unique. If you're importing from a foreign transaction manager then the particiapant or subordinate will have to perform a mapping, similar to JCA for example.

All of the Web Services specifications I've worked on since 1999 have used a URI for the txid. It hasn't caused any problems that I'm aware of. If you've got concerns I'd be interested in hearing them.

Mark, I agree with you that a URI makes perfect sense in the Web and for transactions, and that a URI may perfectly identify a transaction. However, I can't understand why, in the Web services transactions realm, we need to perform a mapping like the one a resource adapter performs in the JCA transaction inflow mechanism. Wouldn't things be easier if WS-AT defined a format to propagate a xid (in fact, just the format id an the global transaction id)? This way, there would be no need for mappings. In the OTS transaction context, for example, the spec says where both the format id and the global transaction id should be placed (in the structure you mentioned in the previous post). Consequently, there is no need for mappings in OTS.

If what I have written so far is not clear, I will try to explain my doubt in another way. XA is the relevant standard for interactions between the TM and the RMs. The work performed in any RM is always tied to a xid. In a distributed transaction, all the RMs involved should (they should, but do not have to) be tied to the same format and global transaction identifiers. Therefore, these two identifiers should be conveyed in the WS-AT transaction context that is injected in transactional SOAP calls. The problem is that WS-AT does not define how to convey the two identifiers, and so the propagation of the identifiers has to be made in an implementation-specific way. This does not break interoperability in multi-vendor environments, but may result in RMs managing more branches than strictly necessary.

Don't you think things would be simpler if WS-AT defined a structure to propagate a xid, like OTS does?

[jhalliday]

> Don't you think things would be simpler if WS-AT defined a structure to propagate a xid, like OTS does?

Yes :-)

I agree it's a pain when writing transaction bridging i.e. WS-AT<->JTA/XA interop. It's going to impact the use of JTA as the interface to WS-AT (per JSR-156) too. Maybe something to put on the agenda for WS-AT 1.2...

[marklittle]

"ivanneto" wrote:
Mark, I agree with you that a URI makes perfect sense in the Web and for transactions, and that a URI may perfectly identify a transaction. However, I can't understand why, in the Web services transactions realm, we need to perform a mapping like the one a resource adapter performs in the JCA transaction inflow mechanism. Wouldn't things be easier if WS-AT defined a format to propagate a xid (in fact, just the format id an the global transaction id)? This way, there would be no need for mappings. In the OTS transaction context, for example, the spec says where both the format id and the global transaction id should be placed (in the structure you mentioned in the previous post). Consequently, there is no need for mappings in OTS.

Putting my Devil's Advocate Hat on ...

The reason we did it in OTS was pretty obvious: XA integration is the most common use for OTS. In Web Services it's a bit different. Although WS-AT can be used for TM-to-TM interoperability, it can also be used for consensus between Web Services: there's no need to backend your participants with databases or anything that would necessarily understand XA at all. If you look back at all of the other Web Services transactions specifications (with the exception of XAML), you'll see that they took a very deliberate choice to distance themselves from XA in the default, and support atomicity as a protocol. From a SOA perspective, the fact that you are using XA should not be exposed to users, i.e., shouldn't be visible on the wire, because it's an implementation issue.

Taking the hat off now ...

We could have produced a standard representation of an XID within a URI. It never came up as a priority.

If what I have written so far is not clear, I will try to explain my doubt in another way. XA is the relevant standard for interactions between the TM and the RMs. The work performed in any RM is always tied to a xid. In a distributed transaction, all the RMs involved should (they should, but do not have to) be tied to the same format and global transaction identifiers.

In a distributed heterogeneous environment (the kind you'll find Web Services used) this is going to be rarely the case.

Therefore, these two identifiers should be conveyed in the WS-AT transaction context that is injected in transactional SOAP calls.

Yes, but you should also remember that WS-C and WS-AT are for coordinator and consensus only. Like OTS, the other critical aspects of providing transactional semantics (concurrency control, durability) aren't defined. In a Web Service transaction, the fact you are coordinating XA-aware participants isn't necessarily known to the coordinator at the time you create/start the transaction. That's not the case with OTS, which is why we also developed the Additional Structuring Mechanisms for the OTS, which provided a separate way of identifying coordinators that didn't understand XA. WS-C and WS-AT have their heritage with that spec (as does WS-CAF).

The problem is that WS-AT does not define how to convey the two identifiers, and so the propagation of the identifiers has to be made in an implementation-specific way. This does not break interoperability in multi-vendor environments, but may result in RMs managing more branches than strictly necessary.

Don't you think things would be simpler if WS-AT defined a structure to propagate a xid, like OTS does?

We could have defined an XA format for URI, yes. Will it happen? I doubt it within a standards body.

[marklittle]

"jhalliday" wrote:
> Don't you think things would be simpler if WS-AT defined a structure to propagate a xid, like OTS does?

Yes :-)

I agree it's a pain when writing transaction bridging i.e. WS-AT<->JTA/XA interop. It's going to impact the use of JTA as the interface to WS-AT (per JSR-156) too. Maybe something to put on the agenda for WS-AT 1.2...

I doubt it. JTA doesn't expose transaction ids to the user anyway.

[ivanneto]

"jhalliday" wrote:
I agree it's a pain when writing transaction bridging i.e. WS-AT<->JTA/XA interop.

Exactly! Some time ago I was working with that and realized a format for xid propagation would have been nice.

Maybe something to put on the agenda for WS-AT 1.2...

It would be good to see that in WS-AT 1.2. :-)

[ivanneto]

Thank you for your helpful answer Mark. I understand things better now.

[marklittle]

"ivanneto" wrote:
Thank you for your helpful answer Mark. I understand things better now.

Glad to help.

[reverbel]

"ivanneto" wrote:
The work performed in any RM is always tied to a xid. In a distributed transaction, all the RMs involved should (they should, but do not have to) be tied to the same format and global transaction identifiers.

In a distributed heterogeneous environment (the kind you'll find Web Services used) this is going to be rarely the case.

What if a distributed transaction involves two WS-AT implementations that access the same RM? Multiple application servers sharing the same database back-end are not that uncommon... If two such servers offer transactional WS access, you are likely to end up with the RM getting (through different application servers) different global ids in work requests that should be associated with the same global transaction. Depending on what the distributed application does, you will experience deadlocks.

[marklittle]

Why would they be different global ids?

The transaction id is defined by the coordinator and is returned in response to a begin request. In your example the user application would propagate the same TxId to both AS instances. Since neither instance needs to know about the other, in all likelihood they'll both attempt to do a START and one of them will get an error. One option would then be to throw that exception back to the user and abort the transaction. But that doesn't really help. Alternatively, the TM could then (on catching the exception within the AS instance) create a new interposed Xid using the global TxId from WS-AT as the key in a durable map of some kind.

[marklittle]

"reverbel" wrote:
Depending on what the distributed application does, you will experience deadlocks.

You are correct though in that deadlocks could result in some situations.