Fwd: Re: [Zope] zope operations atomic?

kapil thangavelu k_vertigo@yahoo.com
Wed, 31 Oct 2001 09:28:55 -0800


----------  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 )

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