Comment 17 for bug 322887

Upon closer inspection, it seems likely that the problem might be in the Connection._check_disconnect method of the storm.database module. It handles the situation when there is a database disconnection but lets other exceptions such as the ProgrammingError go through:

    def _check_disconnect(self, function, *args, **kwargs):
        try:
            return function(*args, **kwargs)
        except DatabaseError, exc:
            if self.is_disconnection_error(exc):
                self._state = STATE_DISCONNECTED
                self._raw_connection = None
                raise DisconnectionError(str(exc))
            else:
                raise

It seems that exception might be percolating up to the point where one of the Zope3 threads doesn't commit a transaction. This might be a likely reason why an UPDATE process might endup waiting on an <IDLE> in transaction process. This is a deadlock until the latter process commits its transaction.

Now, whether the ProgrammingError exception should be handled in this method or higher up the stack remains to be determined.