Maciej Wisniowski wrote at 2006-11-17 22:12 +0100:
... That was problem when during one request there was only one call to a StoredProcedure. During that call database connection was created (_v_database_connection) and SP raised exception.
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? In fact, the "_v_database_connection" is *NOT* necessary to abort(rollback) commit the transaction: The call to the stored procedure must register with Zope's transaction system. This registration contains a reference to the connection via which the database transaction can be controlled: i.e. aborted (rolled back) or committed. After the registration, the "_v_database_connection" can disapear without effect to the transaction cleanup.
It is because StoredProcedures in DCOracle2 are a bit strange. They're resource managers itself, but they're using another resource managers from db.py.
Okay, that might be a problem. Do you understand why they are resource managers themselves. 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. -- Dieter