Hello, the problem still exists, as you can see in my comment #20 I 
continue having problems after the commit.

Marking as resolved as nobody has complained since the commit was added.

OK, tanks for de advise, we are reasonably satisfied with de SQL 
Session Handler, even if the native PHP Session Handler was faster for 
an independent system

If you manage to setup a Distributed Hashtable and use it for session 
storage, you'll probably find that in some cases it will perform worse 
than the SQL sessionhandler. If you update the calender view in 
Kronolith for instance, in Firefox up to six listEvent processes will 
run concurrently. But since they will all try to lock the session at 
the same time and have identical backoff intervals, it will require at 
least 500 ms before they finish. The SQL sessionhandler will run these 
processes in parallel, without having to wait for a lock. In my 
system, the SQL session handler is noticeably faster.

See also http://bugs.horde.org/ticket/13231

No, sorry. With de new Db.php the error is the same.

I think that the problem is caused by calling setLogger without a 
prior SetCache when you pass $cache as false.

Without knowing if this is not the intended behaviour or if this my 
break some other thing with this change:

         if ($cache && !isset($config['logger'])) {
             $ob->setLogger($this->_injector->getInstance('Horde_Log_Logger'));
         }

the error goes away,

I know that in this situation the logger instance is not atached to 
the individual read and write db objects

I know that the performance is worse with SQL Session Handler but we 
have Horde installed in two diffent systems and if we use Standard PHP 
Session files we have locking problems, and we haven't been able of 
getting the "Distribute Cache Table" option to work

Maybe this helps.

FWIW - from a performance perspective, nobody should be using SQL as a 
session handler.

Changes have been made in Git (master):

commit 664063d11ea9d30bd9e9f66d13203bb4a521b7ce
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Sep 3 17:28:12 2014 -0600

     Don't attach logger to base split read object

     Bug #13463

  framework/Core/lib/Horde/Core/Factory/Db.php |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)

http://github.com/horde/horde/commit/664063d11ea9d30bd9e9f66d13203bb4a521b7ce

Yes I have split read/write since we have two servers qith the same URL
I use SQL SessionHandler
and no I don´t have SQL Logging, now I'm using SYSLOG

Regards

If that is true, then this is some kind of very obscure bug that 
involves execution order.  (Do you use a split read/write setup?  Do 
you use DB for logging?)

Sorry, doesn't  work for me, I've replace the Db.php file and got the 
same error.

The attached file dows work but this is only a test and don't know if 
is a valid solution for the other bug.

Yes. I replaced the version from PEAR of Horde/Core/Factory/Db.php by 
the one from Git (there are more changes in it than just this) and 
after that, the SQL session handler can be used again.

Does this patch fix?

I don't have time right now to track down why this fixes so this is 
not fixing the underlying problem - only the initiation of the problem.

Changes have been made in Git (master):

commit 0688cd531929ffab5a0f44dd2a6e3f7efd7c2abb
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Mon Sep 1 13:54:18 2014 -0600

     Bug #13463: Possible fix

  framework/Core/lib/Horde/Core/Factory/Db.php |   10 ++++++----
  1 files changed, 6 insertions(+), 4 deletions(-)

http://github.com/horde/horde/commit/0688cd531929ffab5a0f44dd2a6e3f7efd7c2abb

I've been debugging the problem and determined that the problem is in 
the changes changes in the file Horde/Core/Factory/Db.php

If I revert only this file to the one of the previous version of 
Horde_Core all seems to work fine again.

Looking at the changes I think I've found that the problem is caused 
doing the call to $ob->setCache after $ob->setLogger

I've changed the code to look more like the old version and calling 
$ob->setCache prior to $ob->setLogger and works fine

If you need the changed code let me know

I don't know if this may help.

In previous version 5.2.0 If got the same error but in that moment the 
problem was caused by a problem accessing the horde log file (Was 
changed to file instead syslog and after upgrade the apache user did 
not have write access to the file).

Solving the problem the SQL error stopped. Strange?

I have no idea, but I'm not really the SQL guy.

I would tend to agree with Jan - this was a preexisting bug that just 
recently manifested itself because of the way things are setup/torn 
down.  Changing factories triggered the bug, but didn't cause it.

From the SQL driver:

         /* Close any open transactions. */
         if ($this->_db->transactionStarted()) {
             try {
                 $this->_db->commitDbTransaction();
             } catch (Horde_Db_Exception $e) {
                 return false;
             }
         }

Seems like a issue in the DB adapter.  Because if 
$this->_db->transactionStarted() is true, that assumes that there is 
an active connection.

This could be due to the fact that I'm using SQL for IMAP caching, 
which might trigger similar behavior as the SQL sessionhandler.

Is there anything else I can/need to do to resolve this? Do I need to 
post another backtrace like Jan already did? I see this happening with 
the SQL sessionhandler.

I made some changes in the DB factory that fixed an issue with 
infinite looping if SQL was being used as a cache driver.  But I don't 
see anything wrong with that code that would cause this issue directly.

Could be some shutdown order race condition:

[Fri Aug 22 18:55:33.865966 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP Fatal error:  Call to a member function 
commit() on a non-object in 
/home/jan/horde-develop/framework/Db/lib/Horde/Db/Adapter/Pdo/Base.php 
on line 268, referer: http://neo.wg.de/headhorde/kronolith/
[Fri Aug 22 18:55:33.866062 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP Stack trace:, referer: 
http://neo.wg.de/headhorde/kronolith/
[Fri Aug 22 18:55:33.866091 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP   1. {main}() 
/home/jan/horde-develop/horde/services/ajax.php:0, referer: 
http://neo.wg.de/headhorde/kronolith/
[Fri Aug 22 18:55:33.866126 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP   2. Horde_Core_Ajax_Application->send() 
/home/jan/horde-develop/horde/services/ajax.php:70, referer: 
http://neo.wg.de/headhorde/kronolith/
[Fri Aug 22 18:55:33.866160 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP   3. Horde_Core_Ajax_Response->sendAndExit() 
/home/jan/horde-develop/framework/Core/lib/Horde/Core/Ajax/Application.php:241, referer: 
http://neo.wg.de/headhorde/kronolith/
[Fri Aug 22 18:55:33.866193 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP   4. Horde_SessionHandler->__destruct() 
/home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler.php:0, referer: 
http://neo.wg.de/headhorde/kronolith/
[Fri Aug 22 18:55:33.866260 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP   5. session_write_close() 
/home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler.php:115, referer: 
http://neo.wg.de/headhorde/kronolith/
[Fri Aug 22 18:55:33.866293 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP   6. Horde_SessionHandler->close() 
/home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler.php:115, referer: 
http://neo.wg.de/headhorde/kronolith/
[Fri Aug 22 18:55:33.866325 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP   7. 
Horde_SessionHandler_Storage_Sql->close() 
/home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler.php:150, referer: 
http://neo.wg.de/headhorde/kronolith/
[Fri Aug 22 18:55:33.866358 2014] [:error] [pid 5172] [client 
192.168.60.176:57606] PHP   8. 
Horde_Db_Adapter_Pdo_Base->commitDbTransaction() 
/home/jan/horde-develop/framework/SessionHandler/lib/Horde/SessionHandler/Storage/Sql.php:77, referer: 
http://neo.wg.de/headhorde/kronolith/

Setting the log level to DEBUG is sufficient.
Confirmed, though I only see this in Kronolith's Ajax requests.

The latter probably means placing 'Horde::debug' somewhere 
strategically around line 268 in 
/usr/share/php5/PEAR/Horde/Db/Adapter/Pdo/Base.php?

Having said that, I probably already found the culprit. I use the 
'SQL' session handler. When I switch to 'Filesystem storage', there is 
no problem. Switching back to 'SQL' and the problem is back.

I don't see any issues, and have a similar setup. Is this with any 
action or only those two? And please provide a backtrace.

After upgrading to Horde_Core-2.13.1, every attempt to display an 
e-mail or agenda event fails and results in the following error 
message being logged:

[22-Aug-2014 08:47:14] WARNING: [pool www] child 16880 said into 
stderr: "NOTICE: PHP message: PHP Fatal error:  Call to a member 
function commit() on a non-object in 
/usr/share/php5/PEAR/Horde/Db/Adapter/Pdo/Base.php on line 268"

Downgrading to Horde_Core-2.13.0 immediately fixes things. I'm using 
SQL for pretty much everything, except for the Horde_Cache (which uses 
the filesystem).