|
Martin Pool
mbp at samba.org
Thu Jun 27 08:36:58 EST 2002
On 26 Jun 2002, Nik Barron <Nik.Barron at pennantplc.co.uk> wrote: > Hi, > > I'm working on an XML application using mod_python. Without going into too > much detail, what it does is suck an XML file into memory and then allow > multiple users to work on the in-memory copy via the web. The main reason > for this is performance, as processing the file on the initial load is slow, > and also to provide granular locking (the file is split into 1500 or so key > elements, and the locking needs to be per element). > > This works fine in Win32; I do the locking by a simple dictionary, e.g. if > user nik is editing requirement foo, editLocks['foo'] = 'nik' and so on. > This seems to work as expected. How do you make other threads wait for editing on foo to finish? By busy-waiting? > However, I am in the process of moving it over to a Linux box for various > reasons. The code works, but it appears (I'm investigating in more detail at > the moment) that it is now running multiple instances, i.e. the locks > disappear between HTTP accesses. I'm guessing that this is because Apache on > Win32 is run as a single process, but as multiple processes on Un*x. Yes, that is the correct explanation. > Is there a reliable way of handling such 'multi-user' persistent data under > Un*x, e.g multiple httpds pulling from the same Python? I'm guessing not :( Not directly as far as I know. In theory it might be possible using Apache 2.0's MPM, though I'm not sure if it would be a good idea even there. The standard approach is to keep some kind of external shared storage between the different children. If you just need to share a single hashtable, Python's 'shelve' library could be quite simple to use and satisfactory. Things based on some kind of shared-memory DB will not necessarily be any slower than threads in a single memory space. To make you feel better about this, there are some benefits to the Unix approach: - it's more robust in the case where there's a bug that crashes or hangs a single process child - on the whole I suspect you will be better able to execute concurrently with multiple Python interpreters rather than a single image - you may have fewer concurrency bugs if data is private by default (separate processes) rather than shared by default (single image) Cheers, -- Martin don't buy anything from Radio Shack -- http://radioslack.com/
|