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

[M_Boosten <mboosten@xxxxxxxxxxxxxxxxxxx>]

Hi Oyvind, Bernard Sufrin, and others,

Oyvind wrote:
> Marcel writes (more far below):
> > 3. As far as I know, it has been completely ignored by the 
>      CSP community
> Bernard Sufrin mentions database transactions in his eCSP documents:
> http://web.comlab.ox.ac.uk/oucl/work/bernard.sufrin/
> 
> He has something he calls SERVICE and ASPECT.
> "Database liaison for services is via abstract table descriptions"
> I don't know if this matches your thoughts, Marcel.

Thanks for pointing me to this article.  I hadn't seen it before.

I don't think Bernard Sufrin or Quentin Miller were at CPA2000
conference... too bad.

Very interesting article.  I suppose somewhere there must be documented
comments from Peter Welch, Adrian, and other researchers in the area
of CSP on this document...

Q: can someone point me to such comment?

Sufrin's/Miller's SERVICE and ASPECT are means to create and connect
Processes on request:  An essential concept to make a CSP-based language
useable in most (say 90%) of the situations.

I'm glad Sufrin and Miller didn't mention DATABASE TRANSACTION as a
communication/synchronisation concept.  It is not a primitive, but a
higher level concept.  It is something you must be able to construct
from a language, but not something that should be `cooked' into a
language.  For the same reason, I'm glad they didn't mention BUCKET,
SEMAPHORE, RESOURCE, and EVENT.  A proper primitive allows building these
higher level primitives without loosing significantly (and mathematical
order difference) in performance.

However, when describing the higher-level primitives, the DATABASE/TRANSACTION
primitive should not be left out, in my opinion.

I like the approach where a single primitive is chosen as THE primitive.
I suggested to use the SYNC as that primitive.  I get the impression that
people start to feel where I'm heading with the SYNC.

What do all of you think?
Cheers,
	Marcel