Hi, I have a method which increments an attribute on the current object. I have created a thread lock so that multiple threads accessing the method simultaneously cannot stuff up the attribute value: lock = thread.allocate_lock() def nextOrderNumber(self): lock.acquire() self._order_number = self._order_number + 1 lock.release() return str(self._order_number) My concern is that even though a second thread is halted at "lock.acqure()" while the first thread updates the order_number, that the second thread has an 'out of date' version of 'self' with the original order_number value in it, hence, is still returning the incorrect order_number. Do I need to explicity get the order_number attribute from the ZODB somehow, rather than grabbing it from 'self'? terry -- Terry Kerr (terry@bizarsoftware.com.au) Bizar Software Pty Ltd (www.bizarsoftware.com.au) Phone: +61 3 9563 4461 Fax: +61 3 9563 3856 ICQ: 79303381
Terry Kerr wrote:
I have a method which increments an attribute on the current object. I have created a thread lock so that multiple threads accessing the method simultaneously cannot stuff up the attribute value:
The ZODB doesn't work like that ;-) As I understand it, each DB connection gets it's own consistent copy of the ODB, so you don't need to worry about locking...
def nextOrderNumber(self): lock.acquire() self._order_number = self._order_number + 1 lock.release() return str(self._order_number)
My concern is that even though a second thread is halted at "lock.acqure()" while the first thread updates the order_number, that the second thread has an 'out of date' version of 'self' with the original order_number value in it, hence, is still returning the incorrect order_number.
Indeed. The is called conflict resolution and your problem is solved as an example in: http://www.zope.org/Documentation/Articles/ZODB2 ...in the section "Resolving Conflicts" Personally, I'd use a file-based counter or auto incrementing sequel column. cheers, Chris
Chris, I notice in the ZODB2 article that it states that the conflict resolution method "should return the state of the object after resolving the differences.". However, in the example the method only returns the portion of the state that was deamed to be in conflict. Shouldn't it be returning the entire new state dictionary? terry Chris Withers wrote:
Indeed. The is called conflict resolution and your problem is solved as an example in: http://www.zope.org/Documentation/Articles/ZODB2 ...in the section "Resolving Conflicts"
-- Terry Kerr (terry@bizarsoftware.com.au) Bizar Software Pty Ltd (www.bizarsoftware.com.au) Phone: +61 3 9563 4461 Fax: +61 3 9563 3856 ICQ: 79303381
On Thu, 13 Sep 2001 09:40:43 +1000 Terry Kerr <terry@bizarsoftware.com.au> wrote:
Chris,
I notice in the ZODB2 article that it states that the conflict resolution method "should return the state of the object after resolving the differences.". However, in the example the method only returns the portion of the state that was deamed to be in conflict. Shouldn't it be returning the entire new state dictionary?
I believe it should, and that the article is in error, but really, I wouldn't go on that without hearing from someone like Jim or Shane. -Michel
participants (3)
-
Chris Withers -
Michel Pelletier -
Terry Kerr