quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Gallacher <jg.li...@sympatico.ca>
Subject Re: FileSession.py - improved? version
Date Tue, 12 Apr 2005 04:30:42 GMT
Hi Grisha,

Gregory (Grisha) Trubetskoy wrote:
> 
> On Mon, 11 Apr 2005, Jim Gallacher wrote:
> 
>> There will still be a race condition when session locking is off, but 
>> at least the integrity of the session files is preserved. This race 
>> condition should be noted in the forthcoming documentation though.
> 
> 
> Why not when locking is oh retain the lock for the duration of the 
> request and when locking is off only retain it for the duration of the 
> read/write operation? 

This is exactly what has been implemented. However, as with DbmSession, 
session locking can be turned off. When session locking is off, a lock 
is still acquired for read/write operations to protect the file 
integrity. However, when lock=0, there will be a race condition. Two 
process can have their own copies of FileSession data for a specific 
session at the same time. Even with file locking, one will still 
overwrite the other. It's race. The data stored in the file may not be 
valid, but at least it won't be corrupt. The only way to avoid it is to 
have session locking turned on with lock=1.

Correct me if I'm wrong, but this same race condition exits in 
DbmSession as well, when lock=0.

> A documented race condition doesn't sound like a 
> good idea :-)

True, but it's better than an undocumented race condition :)
The only way I can see around it (the race condition, not the 
documentation), is to make session locking mandatory. Any thoughts?

Regards,
Jim

Mime
View raw message