Re: computational model of transactions
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 02 Aug 2006 01:57:03 GMT
Message-ID: <PDTzg.32009$pu3.428175_at_ursa-nb00s0.nbnet.nb.ca>
>
> To try to clarify even more, even if nobody wants to hear it, all
> program 'artifacts', eg. so-called buffers, ought to be eradicated when
> a transaction ends, in Gray's terms, when locks are released. In other
> words, all transaction memory.
Date: Wed, 02 Aug 2006 01:57:03 GMT
Message-ID: <PDTzg.32009$pu3.428175_at_ursa-nb00s0.nbnet.nb.ca>
paul c wrote:
> paul c wrote:
>
>> paul c wrote: >> >>> Bob Badour wrote: >>> ... >>> >>>>>>> While that's sometimes necessary, the batch processes I referred >>>>>>> to did not all do that. They just grouped multiple logical units >>>>>>> of work together before issuing a commit. Serializing was handled >>>>>>> by the normal concurrency features and isolation level. >>>>>>> ... >>> >>> In that case, you are talking about serialization and not recognizing >>> it. >>> >>> p >> >> (To clarify, if the so-called luw's could have been run in parallel >> with an acceptable result, the issue of concurrency is moot. I think >> luw is synonomous with transaction in Gray's sense, even though I know >> some programmers think program trumps transaction. ...
>
> To try to clarify even more, even if nobody wants to hear it, all
> program 'artifacts', eg. so-called buffers, ought to be eradicated when
> a transaction ends, in Gray's terms, when locks are released. In other
> words, all transaction memory.
That seemed to come out of left field, and I am having trouble identifying the relevance or the point. Received on Wed Aug 02 2006 - 03:57:03 CEST