[Dbix-class] Caching connections

[Tim Sweetman]

Dan Horne wrote:

> It's not for security - it's for transactional safety. Consider a case 
> where
>
>user A starts a longish (5 second) transaction, and user B starts one
>shortly after, but it fails immediately and rolls back - well this would
>roll back A's transaction too if the same database handle was used.
>  
>
You said elsewhere that you weren't trying to make transaction span 
multiple HTTP requests.

In that case, is something else odd going on? Are you running multithreaded?
Normally, I'd expect user A and user B to inhabit, at any point in time, 
different Perl processes. B's rollback can't affect A, because it's not 
in the same process. The only thing you'd have to worry about is 
"contaminating" the global or cache state with a handle that was logged 
in as the "wrong" user. Storing a hash of DB handles, or schemas, keyed 
on usernames seems a reasonable solution, if this doesn't cause any 
performance issues.

(Apparently it is possible to tie a particular user to a particular 
server process using FastCGI; there's a "session affinity" patch for 
Apache which allows this).

Tim