Please do not create new tickets for existing issues.

As continuation of the BUG I've doing some tests with the SQL Session 
Handler and found that adding a __destruct method to this object which 
do a call to the close method al seems to work fine.

Now the SessionHandler/Storage/Sql  does not have an specific 
destructor and none is called, I've introduced one that is called 
prior to the Db/Adapter/Base one and then the transaction is closed in 
time.

I don't know if, even in this case, we can have a race condition in 
which the Db/Adapter/Base object may be destroyed prior to the 
SessionHandler/Storage/Sql, and then the error will be still there

I attach a patch with two changes, one is de mentioned before and one 
for a simplified version of Core/Factory/Db.php

Hello again, I've just installed de last version (5.2.5) of Horde 
webmail and the problem with bug #13463 is still there and getting 
worse.
I think that I have some new information, the error is produced 
because a SessionHandler (Storage Sql) commit is started after the Db 
object has been disconnected.
The situation is produced when destructors (__destruct) are called for 
the  Db/Adapter/Base object (which is processed first and disconnects 
the database object) and for the SessionHandler object which calls to 
session_write_close and closes the session after the commit of the 
last active transaction, but in this moment the underlying Db object 
does no exists.

Seems that SessionHandler maintains an open active transaction all the 
time after the first read  I don't know if this can be modified or if 
there is a way to force an explicit close of SessionHandler before the 
object rundown