Re: ACID et al

vc wrote:
> paul c wrote:
>

>>vc wrote:
>>
>>>paul c wrote:
>>>
>>>
>>>>I'm interested to see any comments the group has on something I'm
>>>>(haphazardly) working on which in part has to do with guaranteeing the
>>>>ACID properties without locking.
>>>
>>>
>>>Locking (or any other concurrency mechanism) is relevant only to, well,
>>>concurrent transactions.
>>
>>Yes, another way to say what I meant might be that such an implemention
>>wouldn't support concurrent transactions, only concurrent users!

No. No 'transaction' is ever concurrent with another, regardless of whether it contains 'reads' and/or 'writes'. I say 'single-threaded' only because if I said 'single process', somebody might infer that multiple-threads were possible.

A single messages passes for a 'transaction'. (It could also pass for several 'transactions', but I won't get into that just yet.) A message might read 10 tables and write 5 tables. The client would indeed have to support receiving the contents or partial contents of numerous tables, however I wouldn't expect multiple returned relations to be handled necessarily by user-written code.

(I don't mean to sound dictatorial and I realize that since it's only on paper at the moment, I could get away with saying anything I want, but I wanted to double-check my knowledge here before I started trying to code something. It is most important to me, since I'm the only programmer available, to be ruthless about excising traditional functions. Another reason is that even if there many programmers I would want to minimize the number of concepts to master. The A,I and D letters seem no problem to me. My big concern wrt 'transactions' is coming up with a high-performance way to ensure Consistency, aka logical integrity with minimal code which at the same time means with a minimal interface/api language.)

thanks,
p Received on Mon Dec 05 2005 - 20:29:35 CET