[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Database transactions, a Higher-level primitive in CSP?
Hi Oyvind, Bernard Sufrin, and others,
> 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:
> 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?