On Sun, 2004-03-07 at 21:13, Chris Ochs wrote: > Been doing some more testing on this. Previously I was untying the > sessions when the handler was finished. But it seems that all it takes is > just one child to exit uncleanly where I cant' catch the error and untie the > sesssions, and that's all it takes to cause corruption. If I untie the > session variables at the very start of the handler everything works fine.
What do you mean by untying the sessions? Can you show us some code? All you should need to do is make sure the session object goes out of scope, which will happen even if your code dies. > As far as performance, I would say any db file implementation would be > slower if you are using lock files, because you can't have concurrent access > on the same file. The file store is about 8 times as fast as DB_File in my > setup. BerkeleyDB handles its own locking and thus does not require any lock files. > BerkeleyDB is fast, but in concurrent data store mode which is the easiest > to use when you want concurrent access, you still have to write to disk on > every access to flush the memory cache to disk or other processes won't see > the latest writes to the database. At least that has been my limited > experience anyways. That hasn't been my experience. I've never needed to do anything explicit in order to get the data to be shared. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
