RE: [INTERFACES] Transaction support in 6.5.3/JDBC
От | Peter Mount |
---|---|
Тема | RE: [INTERFACES] Transaction support in 6.5.3/JDBC |
Дата | |
Msg-id | 1B3D5E532D18D311861A00600865478C70BF20@exchange1.nt.maidstone.gov.uk обсуждение исходный текст |
Список | pgsql-interfaces |
-----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Wednesday, December 08, 1999 9:07 AM To: Peter Mount Cc: 'Assaf Arkin'; pgsql-interfaces@hub.org Subject: Re: [INTERFACES] Transaction support in 6.5.3/JDBC 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. > 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 ************
В списке pgsql-interfaces по дате отправления: