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

[Alexei Ustyuzhaninov]

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.

-- 
Alexei