CGIs and file exclusion

Diez B. Roggisch deetsNOSPAM at web.de
Fri Nov 5 13:27:37 CET 2004


> Ok, but then I guess you need an external long-living process keeping the
> DB open for you. If the cgi script opens and close the database by itself,
> the only thing the ZODB buys for you is raising

Oops, yes. I'm not sure if anything else than filestorage will help with
that, but of course my application is a "real" server.


> BTW, it is clear from the traceback than internally ZODB uses fcntl
> and probably a custom solution based on it would be simpler than
> installing the ZODB (unless the OP has some reason to want it).
> But I guess you had in mind something different, care to explain?

I've run into the same tracebacks when my application died and got stale so
starting it up again provoked that locking error.

But this exactly is the reason why I personally would refrain from using a
fcntl-approach. What happens if your cgi process freezes? As I never used
mod_python or similar "primitive" http frameworks, I don't know if
malfunctioning scripts are reliably killed after some time - and even if
they _are_, that would most probably be after at least 30seconds, if not
more.

So to paraphrase my suggestion: Instead of trying to reinvent the wheel of
serialized access to a critical resource from different processes, use some
database abstraction layer. As the OP wanted to use pickle, I guess he's
not interested in OR-mapping his stuff to a RDBMS, but wants to deal with
"pure" python objects - thats why I recommended zodb in the first place.

So maybe a small application server is in order - you could for exampl use
corba, xmlrpc or pyro to connect to that service from the cgi, keeping the
cgi-layer extremely simple.

-- 
Regards,

Diez B. Roggisch



More information about the Python-list mailing list