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 EAA33992 for ; Wed, 8 Dec 1999 04:09:07 -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 EAA26138; Wed, 8 Dec 1999 04:07:18 -0500 (EST) To: Peter Mount cc: "'Assaf Arkin'" , pgsql-interfaces@hub.org Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC In-reply-to: Your message of Wed, 8 Dec 1999 07:26:29 -0000 <1B3D5E532D18D311861A00600865478C70BF1A@exchange1.nt.maidstone.gov.uk> Date: Wed, 08 Dec 1999 04:07:17 -0500 Message-ID: <26136.944644037@sss.pgh.pa.us> From: Tom Lane Peter Mount 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? > 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. > 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? regards, tom lane