[Zope] Database connectors

[Maciej Wisniowski]

>> 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