From: Assaf Arkin <arkin@exoffice.com>
To: Peter Mount <petermount@it.maidstone.gov.uk>
Cc: 'Tom Lane' <tgl@sss.pgh.pa.us>
Cc: pgsql-interfaces@hub.org
Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC
Date: Wed, 08 Dec 1999 11:43:05 -0800
Message-ID: <384EB4C9.14B56E88@exoffice.com> (raw)
References: <1B3D5E532D18D311861A00600865478C70BF20@exchange1.nt.maidstone.gov.uk>
> Peter Mount <petermount@it.maidstone.gov.uk> writes:
> > 1. When a dead-lock occurs trying to update the same row from multiple
> > threads, there does not seem to be any timeout and both connections
> hang
> > forever. Is there any dead-lock detection in 6.5 and will there be on
> in
> > 6.6 or 7.0?
>
> > PM: I'm not sure if there is/will be in the backend. I'm planning on
> > making the OOB abort stuff working for 7.0, but I'm not certain on
> > dead-lock's.
>
> This doesn't seem right to me --- the backend should detect deadlocks
> (not right away, but within a few seconds or a minute at most). If
> it doesn't, that's not JDBC's fault. More details please?
>
> PM: I didn't think it was.
In my opinion the back-end should detect deadlocks, or just connections
that hang too long trying to get something done, and have them properly
terminated.
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.
> Right. Again, this'd be a backend bug if it didn't happen. The backend
> isn't supposed to rely on correct frontend behavior to ensure database
> integrity.
>
> PM: That's what I thought was the case.
Good.
> This one maybe can be blamed on JDBC. In the 2.0 protocol the BE
> will send a cancel security key --- but I seem to recall that the
> JDBC client still requests protocol 1.0?
>
> PM: In theory 6.5.3 should be requesting the current protocol (I
> remember the patch being submitted to me as part of another fix).
> However, I haven't (yet) had chance to look at it yet - hence not
> knowing about the security key. The bit I want to add is for JDBC2,
> ResultSet would by default use a cursor, and if it's closed while a read
> is in effect, it would send cancel to the backend.
I'll try and see if I can get change the protocol and get the pid/key.
I'm only using the pid/key internally, so I don't see the possibility of
someone else interfering. It's not exposed to the code using the JDBC
driver. While the pid is known, the key is no known so one cannot
terminate an operation without creating the connection first. It's up to
the key to be reasonably unguessable.
arkin
>
> Peter
>
> regards, tom lane
>
> ************
>
> ************
--
____________________________________________________________
Assaf Arkin arkin@exoffice.com
CTO http://www.exoffice.com
Exoffice, The ExoLab Company tel: (650) 259-9796
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: arkin@exoffice.com, petermount@it.maidstone.gov.uk, tgl@sss.pgh.pa.us, pgsql-interfaces@hub.org
Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC
In-Reply-To: <384EB4C9.14B56E88@exoffice.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox