the code snippet i posted is part of a daemon process, which has mainly the purpose of serving and cacheing sessions. as now it is going to become (at least an interface to) the engine of a browser game, the amount of work it has to do has grown immensely. the process consists of mainly 4 threads: the main thread listens to a TCP socket and replies to requests coming from ModPerl::Registry scripts ('CGI'). a second thread observes the validity of sessions and invalidates them, if necessary. the third thread is what we're talking about. fourth there is a logging thread.

the problem i have to face is that perl references may not be shared between threads. that's why session objects are being kept frozen on the shared hashtable. and even worse: that's also why the distributor subthread in the event handler has to explicitly connect each time. it would have been a lot less difficult, if i could have opened a pool of cached connections to the database and pass them around my subthreads. but that's a dream. i even tried freezing the db-handle. :(

the EventCooker is a thing which i have umm... borrowed from ModPerl::RegistryCooker. events will be put into the database at relevant user requests: each event is represented by one table row. in order to keep the engine flexible, it wouldn't be appropriate if i packed all event handling code into a bundle of libraries - as then i would have to restart the daemon each time i modified one line. so now, the code which handles a certain type of event, may now be a perl script, which then will be executed by the EventCooker.

what even worsens the story is, that most probably all of these scripts will have to connect again to the database, as they will need further information. but maybe there'll be a workaround for this problem with a more diligent query from the distributor thread.