[Zope] zope operations atomic?

[Kapil Thangavelu]

--- Clark OBrien
<COBrien@isis-server.vuse.vanderbilt.edu> wrote:
> 
> 
> 
> 
> Thanks for the clarification - more comments below.
>                                   clark
> 

no problem. one clarification to my clarification:),
zope threads do not maintain persistent connections to
the zodb, they open a new connection for every
request, the zodb internally stores connection objects
(and associated caches) in a LIFO stack to maximize
cache hits. i'm actually a little unclear when the
these connections are synced up with the db (cache
invalidated).

> >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... 
> 
> atomic implies a set of opperations succeed or they
> have no effect on the
> data.
> 
> 
> suppose I have a method AtoB that changes every
> letter A to B.
> suppose I have another method BtoC that changes the
> leter B to C.
> 
> what is the outcome of invoking these methods in
> different thread contexts
> on the 
> string ABABABAB?
> 

it depends on the concurrency. if both methods execute
concurrently, than one will conflict and one will
commit from trying to write on the same object. which
one is hard to determine apriori... i'm taking a wild
guess that it would be first one to commit. Chris,
could you comment on this?

but what does this mean in terms of atomic operation?
independently running these methods in different
contexts implies that these each forms a separate
atomic operation with the additional set of 
operations in each context respectively. 

so each operation will either succeed or fail, if
their is no consistency check made on the value of the
string, than its possible to achieve different values
depending on timing. the "loser" will retry, but in
either case the operations are still atomic in that
they succeed or fail.

to take a page from chris's rdbms analogy.

an rdbms app might get around this by explicitly
locking the row. so you could know the value of the
string assuming you know the timings of the threads,
and which one gets to the lock first. but unless you
define a consistency check, you're at the mercy of the
thread timings, which is a poor way to determine
consistency for concurrent operations.

> 
> >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.
> 
> No I am not joking, resolving conflicts after each
> request  by simply
> rolling back is easy to implement.
> The problems with concurrent access are with finding
> *intelligent* solutions
> not easy solutions. The zope guys were smart and
> realized that it is only
> rarely 
> that a web application has to deal with concurrent
> access and when this
> happens
> it should be done at the db layer- as the word
> "optimistic" implies. 

concurrent write access that is. as i said previously
in the unquoted material that made up my previous
reply, if you're application has a lot of concurrent
write operations, i would store the data in an rdbms.

> also making manage_changeProperties atomic would be
> an the level of C making
> strcpy threadsafe. unless you are doing embedded
> systems you appreciate such
> features.

lost me here.

cheers

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 )



__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com