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

Reply via email to