Re: Database transactions, a Higher-level primitive in CSP?

[Richard Beton <richard.beton@xxxxxxxxxx>]

M_Boosten wrote:

> I think the following "primitive" should be added:
>
> - TRANSACTION.  A Database Transaction, or transaction for short
>   allows realiable communication between any number of Processes
>   without prior knowledge of their communication behavior.  Processes
>   perform transactions on the Database.  Deadlock situations are
>   detected by the Database, and the deadlock situation is broken.
>   Processes may be asked by the Database to retry their transaction.
>   The Database guarantees the absense of both lifelock and deadlock.
>   During a Transaction, the Database gives a consistent view of the
>   data.
>
> Remarks:
> 1. There is a world of literature on this subject.
> 2. It is a widely and succesfully used communication mechanism.
> 3. As far as I know, it has been completely ignored by the CSP community.

In computer systems, transactions have the following properties:

* they constitute an asymmetric client/server relationship: the client is asking
the server to do something

* data is exchanged between the client and the server (in either or both
directions)

* the server guarantees to succeed fully, or fail. By definition, if a transaction
fails, it will have had no net effect on the internal state of the server (i.e.
rollback of state to that which existed prior to the transaction).

Whether or not the database may deadlock/livelock during a transaction is a
question of correctness of the database. I would suggest that deadlock-freedom is
not inherently a property of a transaction, but of a properly functioning database.
Whilst transactions would normally be expected to rely on deadlock-free servers, a
transaction is just a transaction.

There is a great body of literature dealing with databases and transactions. I have
to confess to being somewhat ignorant of it. No doubt it deals in depth with
issues, inter alia, such as how to deal with error-prone networking between the
client and the server. Here the communication protocol design is important: when
client/server communication fails part way through a transaction, it is necessary
for client and server both to discover that the failure has occurred and for the
server to effect rollback. This communication protocol must itself be
deadlock-free.

On point 3, the proposed occam3 language includes CALL channels and CLAIM/GRANT of
shared channels. These features allow server processes to implement transactions.
They were never called transactions because it is implicit that they cannot fail,
at least not within the occam channel model (it would be a separate issue to
implement a server such that it would return a success or failure code via the call
channel reply, according to its processing result). There is an important
qualitative difference between parallel processing in a system (almost) free from
communication failures, and distributed processing in networks always subject to
communication failures. It is this aspect of distributed processing that is
addressed by transactions, and this is absent from CSP thinking.

Rick

begin:vcard 
n:Beton;Richard
tel;pager:ICQ: 56840977
tel;cell:MSN/Hotmail: richardbeton@xxxxxxxxxxx
tel;fax:01794 833434
tel;work:01794 833458
x-mozilla-html:TRUE
url:http://www.beton.freeserve.co.uk/
org:Roke Manor Research Limited;Internet Technology & Networks
adr:;;Roke Manor: http://www.roke.co.uk/;;;SO51 0ZN;UK
version:2.1
email;internet:richard.beton@xxxxxxxxxx
title:Internet Consultant
note;quoted-printable:The information contained in this e-mail is confidential and must =0D=0Anot be passed to any third party without permission. This =0D=0Acommunication is for information only and shall not create =0D=0Aor change any contractual relationship. =0D=0A
fn:Rick Beton
end:vcard