---------- Forwarded Message ---------- Subject: Re: [Zope] zope operations atomic? Date: Wed, 31 Oct 2001 08:35:16 -0800 From: kapil thangavelu <kthangavelu@earthlink.net> To: Clark OBrien <COBrien@isis-server.vuse.vanderbilt.edu> On Wednesday 31 October 2001 11:25 am, you wrote:

I don't want to be dense but it sounds like for each thread a deep copy of the items it accesses- Folder for example- is made. When session ends or something triggers a commit a check is made for conflicts.

each thread maintains its own connection to the zodb, and each connection mantains its own cache. when you load up on object you are not deep loading, your loading up all of that object's data minus any persistent attributes it might have. so in a given folder stuffed with standard zope objects you only load up that folders attributes unless you explicitly access the other peristent objects. objects get stuffed into cache after access, for faster lookups. as chris mentioned zope treats every web request as a transaction. when a thread tries to commit an object it, the db checks to see if it has been updated since the transaction began, in which case you get a conflict. so what does atomic mean, that a given set of operations either succeeds as a whole or fails. the zodb passes this standard. the issue you seem to layout below is that your more comfortable with explicit locking...

This sounds a bit scarry because if you have a script changing resources like a Folders it is almost certain then that there will be a conflict. At this point a retry still find conflicts. I would rather have heard the Folder was a critical section or methods like manage_changeProperties were atomic. IMHOP it should be so.

your joking, right... besides the fact that excessive locking kills performance and scalability, i *know* i don't want to have to litter my code with locks and thinking about concurrency. the zodb greatly mitigates concurrency issues, making them almost non-existent for most code. moving from this paradigm to some application level locking paradigm greatly complicates code and would make it damm near impossible to be productive with zope, IMO. IMO, the fact the platform itself takes care of this, and the thread local storage programming model is strength of zope. in the case above if a retry still generates an error, than it will eventually abort the entire transaction (preserving integrity). if you need high concurrency write oriented semantics i'd highly suggest you use an rdbms. and of course nothing prevents you from creating locks around your objects if you feel its nesc via a module stored lock and/or creating your own conflict resolution policy as described in the zope developer's guide. kapil

-----Original Message----- From: kapil thangavelu [mailto:kthangavelu@earthlink.net] Sent: Wednesday, October 31, 2001 3:03 AM To: Clark OBrien; 'zope@zope.org' Subject: Re: [Zope] zope operations atomic?

On Wednesday 31 October 2001 07:11 am, Clark OBrien wrote:

...

Hi: I cannot find documentation that would tell me how zope manages thread synchronization

nutshell version.

zope uses optimistic conflict resolution, no application level locking takes place, because all threads have their own object spaces. only on commits, is there some synchronization (deep within the zodb) to insure that there weren't conflicts, if so a conflict error is raised, and the request gets retried. applications can define their own conflict resolution, see the zodb wikis and zope developer's guide for more details.

kapil

_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

-------------------------------------------------------