On Mon, 2005-06-13 at 00:51 +0200, Kjetil Kjernsmo wrote: > To elaborate on some details from there, things go wrong when we > invalidate a session, as the session is supposed to be untied. However, > as described in the Camel Book (pp. 395), this can't happen because we > still have references to the tied object. The problem is that we don't > understand _why_ we have references to the tied object.
It has little to do with tie() -- you just have a garden-variety scoping problem here. You need to figure out where you are creating the second reference to the object returned from tied(%session). You can use Devel::Peek (or Scalar::Util) to check at which point the second ref is created. Ideally, I would suggest you stop putting your session in a global. That's just asking for trouble. If you put it in $r->pnotes() instead, you will never have to worry about it persisting and you can get rid of the cleanup handler. By the way, it is not safe to use DB_File without locking. Unlike BerkeleyDB, DB_File does no internal locking. You will end up with corrupted or missing data if you don't use your own locks. - Perrin
