Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id UAA15379
	for <pgsql-interfaces@hub.org>; Wed, 8 Dec 1999 20:04:06 -0500 (EST)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id UAA29072;
	Wed, 8 Dec 1999 20:00:32 -0500 (EST)
To: Assaf Arkin <arkin@exoffice.com>
cc: Peter Mount <petermount@it.maidstone.gov.uk>, pgsql-interfaces@hub.org
Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC 
In-reply-to: Your message of Wed, 08 Dec 1999 11:43:05 -0800
	<384EB4C9.14B56E88@exoffice.com>
Date: Wed, 08 Dec 1999 20:00:32 -0500
Message-ID: <29070.944701232@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Assaf Arkin <arkin@exoffice.com> writes:
> I have a very simple test. I start two threads, both of them attempt to
> do an update on the exact same row in the table, both connections keep
> hanging.

Hmm.  The backend doesn't have any trouble detecting this; I checked
both current sources and 6.5.3:

play=> select * from z1;
f1
--
 1
 2
(2 rows)

play=> begin;
BEGIN
play=> update z1 set f1 = 3 where f1 = 1;
UPDATE 1

<now in a second psql do>

play=> begin;
BEGIN
play=> update z1 set f1 = 4 where f1 = 2;
UPDATE 1
play=> update z1 set f1 = 3 where f1 = 1;

<second psql is now waiting for first one to commit or abort>

<back in first psql do>

play=> update z1 set f1 = 4 where f1 = 2;

After a second or so, one psql will say
NOTICE:  Deadlock detected -- See the lock(l) manual page for a possible cause.
ERROR:  WaitOnLock: error on wakeup - Aborting this transaction
and the other will say
UPDATE 1

If you're not getting this behavior, then either your test code is wrong
or there's something broken in the JDBC driver...

			regards, tom lane