From: | Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk> |
---|---|
To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk> |
Cc: | "'Assaf Arkin'" <arkin(at)exoffice(dot)com>, pgsql-interfaces(at)hub(dot)org |
Subject: | RE: [INTERFACES] Transaction support in 6.5.3/JDBC |
Date: | 1999-12-08 10:08:32 |
Message-ID: | 1B3D5E532D18D311861A00600865478C70BF20@exchange1.nt.maidstone.gov.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Wednesday, December 08, 1999 9:07 AM
To: Peter Mount
Cc: 'Assaf Arkin'; pgsql-interfaces(at)hub(dot)org
Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC
Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)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.
> 2. In the event of such a dead-lock, the XA layer will attempt to
> terminate one of the connections. Right now the only recourse is to
> shutdown the connection forcefully, hoping that the transaction is
> rolledback and all locks are released. Am I safe to assume that?
> PM: Someone correct me if I'm wrong, but the transaction should roll
> back if the connection is closed whilst it's open, regardless of the
> interface.
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.
> 3. I would rather cancel the pending update/insert, and according to
the
> interface specs there is a way to recieve a pid/key on startup and use
> it to cancel an operation in progress. However, at the end of the
> authentication process that happens at startup, no pid/key are send to
> the FE, nor does the BE acknowledge that a query can be made.
> PM: Do you mean the pid of the backend running a particular
connection?
> If so, I can see some security headaches if one connection can cancel
an
> operation running on another. As for the BE not acknowledging that a
> query can be made, thats just how the current protocol works.
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.
Peter
regards, tom lane
************
From | Date | Subject | |
---|---|---|---|
Next Message | stuart | 1999-12-08 13:27:23 | missing mail? |
Previous Message | Tom Lane | 1999-12-08 09:07:17 | Re: [INTERFACES] Transaction support in 6.5.3/JDBC |