On 20-Feb-08, at 8:41 AM, Paul Tomblin wrote:
> 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?
Yes it has connection scope, not transaction scope. currval stores the
current value in connections memory.
>
>
>
>
> --
> 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.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate
