[Zope-DB] Re: [Psycopg] Transactions with Zope

Hannu Krosing hannu@tm.ee
Fri, 25 Jan 2002 11:09:10 +0200


Lutz Steinborn wrote:
> 
> Good morning.
> 
> Ok, after 10 hours rebuilding transactions by hand from the postgres
> logfile, I can search now the error. In the postgres-log I can see the
> following: 2002-01-24 07:52:38 [16556]  DEBUG:
> StartTransactionCommand 2002-01-24 07:52:38 [16556]  DEBUG:  query:
> BEGIN; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 2002-01-24
> 07:52:38 [16556]  DEBUG:  ProcessUtility: BEGIN; SET TRANSACTION
> ISOLATION LEVEL SERIALIZABLE 2002-01-24 07:52:38 [16556]  DEBUG:
> CommitTransactionCommand.....
> some quries
> .....
> 2002-01-24 07:52:38 [16556]  DEBUG:  StartTransactionCommand
> 2002-01-24 07:52:38 [16556]  DEBUG:  query: END
> 2002-01-24 07:52:38 [16556]  DEBUG:  ProcessUtility: END
> 2002-01-24 07:52:38 [16556]  DEBUG:  CommitTransactionCommand
> 
> OK, this is the normal situation. Page startet, doing some quries,
> page end.
> 
> But at the 23.01 it was different. All is starting normally but where
> is no END statement for more then 12 ours for 2 or 3 processes. We are
> using the Zope transaction end command in a lot of pages but it never
> comes to the database for this processes. As a workaround we have now
> database commits in our critical pages. Hopefully this works.

We have seen it too and after several of our people sat cross-eyed for 
weeks we may have just found (an ugly ;) solution.

It is a hairy problem deep in Zope transaction management that manifests 
itself when something raises an exception during commit and then the 
finally: clause clears a list of registrees before abort is called.

The short description is that after that happens the DA will not be able 
to register itself with transaction manager any more as it already
thinks 
it is registered. And thus will neither commit nor abort any
transactions 
(and all data will be lost at Zope restart).

We will have a longer discussion on that here later today (about 5 hours 
from now) and then will post a more thorough explanation with a proposed 
fix.

-------------
Hannu