[Zope] zope operations atomic?

[Clark OBrien]

It is what happens with this retrying that interests me. As the example
given
below shows, this retry may never succeed. Thus long running operations may
never complete and are effectively starved by faster running operations.



Assume in Zope I have a folder structure like this.

Folder-1
  -Folder-2
      -Folder-3
         ....
            ..
              Folder-1000


Suppose I have a script traverseFolder(root) that starts at a given root and
traverses sub-folders adding the attribute foo.

If I continuously call traversefolder(Folder-1000) how could
traverseFolder(Folder-1) ever complete. I mean, by the time
traverseFolder(Folder-1) could complete traverseFolder(Folder-1000) would
have already committed several times. What would happen with the request
that started traverseFolder(Folder-1), would it keep being retried ad
infinitum.
It is basically starved out of contention by a faster running operations.


 




-----Original Message-----
From: Chris McDonough [mailto:chrism@digicool.com]
Sent: Thursday, November 01, 2001 11:16 AM
To: Kapil Thangavelu
Cc: Clark OBrien; 'Chris McDonough'; zope@zope.org
Subject: Re: [Zope] zope operations atomic?


AFAIK, a read conflict is raised in this circumstance, so there can't be 
a dirty read.

But again, since requests which raise conflicts are retried, there is 
never a consistency problem.

- C


Kapil Thangavelu wrote:
> even more generally the problem can be stated as
> transaction A starts reads a bunch of objects,
> transaction B starts and will read a set of objects
> that intersects with transaction A. transaction A
> commits changing objects that B is about to read
> (after B has read some objects). B finishes, and has
> possibly  commited or done operations on data that is
> no longer in sync because the set of data may not have
> been consistent for its operation, hence the dirty
> read.
> 
> this is a more interesting and IMO legitimate concern,
> i haven't done any testing recently, but i believe as
> it currently stands this should throw a ConflictError
> (i'm not sure, though.). Jim and pythonlabs have
> talked about setting up some sort MVCC for the zodb,
> whereby transaction B will see a snapshot of objects
> as it existed when it began. if you're interested in
> this further i would send mail to the
> zodb-dev@zope.org list, referencing this thread.
>  
> cheers
> 
> kapil
> 
> --- Clark OBrien
> <COBrien@isis-server.vuse.vanderbilt.edu> wrote:
> 
>>Here is the example I was thinking about.
>>
>>
>>1) Suppose an online store is selling product X and
>>at a 
>>given moment its inventory is n. Two shoppers hit
>>the buy
>>button at about the same time. 
>>
>>Then either:
>>
>>a) No conflict is detected because both threads set
>>the inventory
>>value to the same value, n-1. This would cause a
>>problem if n = 1
>>
>>Or:
>>b) A conflict is detected when the last thread
>>writes because the inventory
>>is not 
>>n as it was when he read it. request is resubmitted
>>but again another thread
>>has 
>>changed made the value dirty- thread starves.
>>
>>
>>
>>
>>
>>
>> 
>>
>>
>>
>>-----Original Message-----
>>From: Chris McDonough [mailto:chrism@zope.com]
>>Sent: Thursday, November 01, 2001 6:50 AM
>>To: Clark OBrien; k_vertigo@yahoo.com; zope@zope.org
>>Subject: Re: [Zope] zope operations atomic?
>>
>>
>>What is "the dirty read problem"?
>>
> 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Make a great connection at Yahoo! Personals.
> http://personals.yahoo.com
> 


-- 
Chris McDonough                    Zope Corporation
http://www.zope.org             http://www.zope.com
"Killing hundreds of birds with thousands of stones"