Re: Retrieving last InsertedID : INSERT... RETURNING safe ?
От | Paul Tomblin |
---|---|
Тема | Re: Retrieving last InsertedID : INSERT... RETURNING safe ? |
Дата | |
Msg-id | 8efd35820802200541p14e99d8bx60ad628302b24f14@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Retrieving last InsertedID : INSERT... RETURNING safe ? (Dave Cramer <pg@fastcrypt.com>) |
Ответы |
Re: Retrieving last InsertedID : INSERT... RETURNING safe ?
|
Список | pgsql-jdbc |
On Feb 20, 2008 8:32 AM, Dave Cramer <pg@fastcrypt.com> wrote: > As far as I can tall Paul has inherited an application which uses a > single connection for all database operations, and is a swing app > which has callbacks which do the following > > Callback code > > grab the global connection object > create a statement > do something > close statement > > in this scenario, since currval has connection scope if two callbacks > are called at the same time, only one will have the right answer . > > Paul am I correct in my assumptions above ? Pretty much, except with the added complication that there are a dozen or so daemons that are also updating the same tables, and up until now they've all had autocommit on. I thought the currval had transaction scope not connection scope, at least that's what my testing in pgsql seemed to indicate, which is why I stated that autocommit was a problem. Are you saying that if in one connection I do a nextval and commit, and somebody else in a different connection does a hundred nextvals and commits, then 20 minutes later I do the currval I'll get the one from my old transaction? -- For my assured failures and derelictions I ask pardon beforehand of my betters and my equals in my Calling here assembled, praying that in the hour of my temptations, weakness and weariness, the memory of this my Obligation and of the company before whom it was entered into, may return to me to aid, comfort and restrain.
В списке pgsql-jdbc по дате отправления: