[Zope-DB] Question: detecting aborted transactions

[jelle]

Hello Chris,

My workflow-type app does 3-20 sql statments per web page. Normally, under 
low load situations, a transaction begins with the first sql statement and 
commits upon completion of the thread. Under high load, Postgresql 
occasionally aborts a statement with the message "could not serialize 
access due to concurrent update" which causes the Zope mechanism to 
silently rollback the transaction. The very next sql statement within the 
same Zope thread starts a new transaction resulting in an funky data.

Perhaps I can solve the problem by (1) committing after each 
statement, and (2) detecting rollbacks and resending the offending sql 
statement after a short delay.

The questions: is that possible within ZSQL and if so how?

Thanks,
Jelle

On Tue, 16 Mar 2004, Chris Withers wrote:

> jelle wrote:
> 
> > I'm using python 2.1.3 -> Zope 2.6.3 -> zope python script -> ZSQL -> 
> > Zpsycopg DA 1.1.11 -> postgresql 7.4.1
> > 
> > The zope python scripts have try-except blocks for each ZSQL call. 
> 
> unless you're cathcing specific exceptions, you don't want to be doing that...
> 
> > Unfortunately an aborted transaction is not caught in the except block.
> 
> Why should it be?
> 
> > The question is how do I detect or determine a transactions aborted
> > from within a zope python script?
> 
> Why do you want to?
> 
> > My problem stems from denial of serialized access because of concurrent 
> > updates.
> 
> ...and in english?
> 
> Chris
> 
> 

-- 

 We live in the era of asymptotic prophecy: The truth, which 
 we'll never arrive at, would make us something like free.
   -S. Klawans