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 ()
Transactions Architect, HP
Arjuna Labs
Phone +44 191 2064538
Fax +44 191
2064203
