The "lock" reference I made refers to my kludge to lock_file.py, to get winlock.pyd working with python 2.4, before it was compiled. I removed my kludge, now that I have good pyd files for python 2.4.
I only mentioned it so I could thank the resonsible parties for the proper winlock.pyd for python 2.4.
So let's not discuss locking. It is not an issue.


The original problem, which is still happening, is the conflict error when a second client connects to the same database. The references I found on the net imply that one has to handle this condition themselves, by either trapping the exception and retrying, or using a semaphore. Are you saying this is not true, and the ZODB/ZEO handles this condition internally?
I hope this is clear.
Thank you,
Gloria


Willadsens wrote:

I am not trying to "lock" anything directly. I have more than one client writing data of the same type to the same DB simultaneously. I wish to keep it this way, instead of doing any other tricks. If I either catch the exception and retry, or check a semaphore, hopefully I won't spend too much time spinning.


It sounds like you're re-inventing a lot of wheels here.

Perhaps you could re-state the higher level problem you're trying to solve?

cheers,

Chris


_______________________________________________ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db

Reply via email to