Re: Some comments on definition of operation/group and action

[Mark Little <mcl@arjuna.com>]

The quoting level is getting a bit deep on this !

I'll try to compensate a bit!

Are you assuming all group members are on the same machine/domain? 

No, definitely not.  

Good. The reason I asked is that such a restriction was mentioned on the last teleconference and I think it's too restrictive. If that were the case then the distinction between operation and group becomes meaningless since an operation could "fan out" internally to multiple actions.

However, data-sharing is only imaginable between group members do get performed on the same machine/domain

                                                                                                      ^^^

                                                                                                       ???

 

(since the data they share is in only "one place").

This is debatable since distributed data sharing works in practice today. There are obviously issues such as security and authentication that will need to be taken into account if the data is shared over different domains, but just because one operation works on machine A does not mean that operation on machine B cannot share data with it. Pragmatically it may not be an issue that we want to tackle in the current BTP timeframe though.

So you're assuming a model whereby failure has to cause some kind of compensation? Or can we leave that to the application, i.e., a failure generates a "failure" message, and how that is interpreted at the group/participant level is up to the model (or participant). Interestingly, strictly speaking I can do something similar in a transaction system: a participant receives a rollback message from the TM and I would hope it does something to undo the work that was done within the scope of the transaction to guarantee ACID properties. However, it doesn't actually need to, i.e., I could build an "extended" transaction model on top of a traditional transaction system by overloading what it means to get a commit/rollback message. 

 

I think "failure" in this environment doesn't necessarily imply just transient process/communication failure, as it usually does in classic TP systems - where there is a expected long duration, one would imagine the components would persist their active-phase state in various ways.

 

Agreed, and we have experience of using such techniques in extended transaction environments with nested transactions: essentially a nested transaction can setup recovery points that are persisted.

Given that,  I think failure does imply cancellation - if the participant implements reversal/cancellation by compensation, then it does.

As long as cancellation is an application level thing that can encompass forward/backward/no recovery I don't have an issue with this.

Just because an operation is compensatable doesn't mean that it should be compensated. It may depend upon factors at runtime. By the time a failure occurs, it may be entirely inappropriate to compensate. Check out the share purchase/selling example in the HP proposal for example. 

 

That kind of means the compensation algorithm is time-dependent - or what was a reversible operation (within the protocol) has now become irreversible.

Yes, and this means that we should not have a model that slaveishly invokes compensations if a failure occurs. This is not a black-and-white decision that the infrastructure should take out of the hands of the implementor/application.

 

Mark.

 

----------------------------------------------
Dr. Mark Little (mark@arjuna.com)
Transactions Architect, HP Arjuna Labs
Phone +44 191 2064538
Fax   +44 191 2064203