Then publisher aborts and rollbacks everything. But first it destroyed database_connection and then Publisher calls abort() for SP - but there is no connection at this moment so no rollback happens.
Have you seen this really? Yes, but as I said I don't remember exactly what was the error. So maybe I've messed something. I'll try to repeat this and give exact description.
But, note that "db.py" is below the "_v_database_connection". If the stored procedure stores a reference to the instance defined in "db.py", then the "_v_database_connection" is again not relevant. Stored procedure does this:
db = self._v_db = getattr(self,self.connection)() # Get connection So seems that self._v_db is a reference to _v_database_connection. If transaction caused new "_v_database_connection" to be created, then is this possible that during this transaction rollback, there is something like: del("_v_database_connection")? Or maybe because of same reference being held in SP.py self._v_db it doesn't happen? I wonder if it is possible that __del__ from db.py is executed: def __del__(self): self.cursor = None # Break reference self.db = None and then, althought self._v_db in SP.py exists, it has no self.db??
Do you understand why they are resource managers themselves. Yes and not. I mean I understand what resource managers are in general, but I don't understand why StoredProcedures from DCO2 are transaction managers itself. Why they're not using transaction machinery from db.py. At last it still uses same self.db. Strange because when during one request you have calls to StoredProcedures and to ZSQLMethods you'll get commits or rollback in oracle twice. Isn't it?
-- Maciej Wisniowski