Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12638
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: "'Michael Ulbrich'" <mul@rentapacs.de>,
	<internals@lists.php.net>
Date: Tue, 7 Sep 2004 21:49:24 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <413CC7F8.1060800@rentapacs.com>
Thread-Index: AcSUT9A5WQjKTc2vRS+kkkcVJmBnTgAw1k2w
Message-ID: <E1C4m35-0000Hp-00@mrelayng.kundenserver.de>
Subject: AW: [PHP-DEV] sybase_ct: deadlock_retry_count
From: thekid@thekid.de ("Timm Friebe")
References: <413CC7F8.1060800@rentapacs.com>

[...]
> My questions to the sybase_ct (Hi Timm ;-) ) maintainer:
> 
> 1. How is the deadlock/retry logic in sybase_ct_query() 
> intended to work? From my understanding a single SQL 
> statement will never deadlock.

I have no idea why this was put in in the first place.

> 2. The default setting of deadlock_retry_count = -1 leads to 
> uncontrolled behaviour, if external transactions deadlock and 
> are rolled back by the server. In this case a clean exit is 
> much better than retrying the LAST statement of the aborted 
> transaction. My suggestion therefore is changing the default 
> to deadlock_retry_count=0.

I have nothing against that. I set it to -1 to ensure backwards 
compatibility. If no one objects, I'll commit that to CVS head.

- Timm