[Zope] How to prevent concurrent access to the same object?

[kapil thangavelu]

hi alexei,

if you really want locking you can do it via a using a module as a shared 
namespace between zope threads to store lock variables.

a simple example in most pseudcode

inside a module SpecialAppFileLocks.py

_lock_storage = {}
_storage_lock = Lock()


def get_lock(file_id):
   _storage_lock.acquire()
   
   file_lock = _locks.get(file_id)
   if not file_lock: 
	_lock_storage[file_id]=Lock()
   _storage_lock.release()
  
   file_lock.aqcuire()

def release_lock(file_id):
    _storage_lock.acquire()
    file_lock = _lock_storage.get(file_id)
    file_lock.release()
    _storage_lock.release()

probably best to wrap the storage locking code in a try: finally clause.

  	
    

hth.

kapil




On Friday 08 February 2002 07:40 am, Alexei Ustyuzhaninov wrote:
> Richard Barrett wrote:
> > At 11:12 08/02/2002 +0500, Alexei Ustyuzhaninov wrote:
> >> Richard Barrett wrote:
> >> > At 10:15 06/02/2002 +0500, Alexei Ustyuzhaninov wrote:
> >> >> Hi!
> >> >>
> >> >> Is it possible to make a zope object which doesn't allow simultaneous
> >> >> access to itself? I mean that if two users call methods of the same
> >> >> object then only one call will process at a time and the other one
> >> >> will wait untill the first call will finish. I tried to fix it up
> >> >> with unix semaphores but with no success.
> >> >
> >> > Why do you want to do this so explicitly?
> >> >
> >> > I believe that Zope is inherently transactional and its own database
> >> > updates are performed atomically with transaction commit, abort,
> >> > rollback and retry apparatus built in.
> >>
> >> BTW is there any method to monitor zope transactions? My experience is
> >> that they have quite peculiar behaviour.
> >
> > How so peculiar?
>
> Well, let me share my story. I have a zope product which should be an
> editor of some special files. The main window of the editor is divided
> into two frames. The left frame is a menu which allows the user to
> choose different views of the file. After choosing an option in the menu
> the corresponding view will be shown in the right frame. Generation of
> the view takes some time on the server and during this time the user can
> choose another option in the menu. This will fire up another transaction
> on the server which may be inconsistent with the unfinished previous
> one. The reason is that both transactions affect the same file which is
> not protected by the zope supervision.
>
> To prevent this situation I need to lock the second transaction untill
> the first one will finish. And because both transactions perform as
> separate unix processes I decided to use semaphores to synchronize them.
>   A two-state semaphore is linked to every editable file. Ideally on
> entry a process waits until the corresponding semaphore be turned off,
> then turns it on itself, and turns off on entry. But this doesn't work
> in life. The second process never gets the semaphore turned off. Seems
> like  it locks the first process some other way and whole system is
> clinched. And that's what is peculiar for me in zope: how (and why)
> future transactions affect the previous ones?
>
> >> > That said, you might want to ask how to plug in your own commit,
> >> > rollback and retry code to zope's transaction commit and abort
> >> > handlers if you problem is to control updating of some external
> >> > database from zope code.
> >>
> >> I think you are right though I don't need sterling transactions in my
> >> objects. I need simple locks.
> >>
> >> So, could somebody advice how to plug in extra code to the zope
> >> transaction machinery?
> >
> > I do not know if it is still upd to date but you could try the material
> > here: http://www.zope.org/Documentation/Developer/Models/ZODB/
>
> Thanks.