--- 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
__________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com