Re: JDBC problem

From: Joachim Achtzehnter <joachim(at)kraut(dot)bc(dot)ca>
To: Cedar Cox <cedarc(at)visionforisrael(dot)com>
Cc: John McKown <jmckown(at)prodigy(dot)net>, BogdanKRomski <b(dot)kromski(at)gaschka(dot)pl>, pgsql-interfaces(at)postgresql(dot)org
Subject: Re: JDBC problem
Date: 2000-08-27 18:36:29
Message-ID: Pine.LNX.4.21.0008271131130.571-100000@wizard.kraut.bc.ca
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Today, in a message to John McKown, Cedar Cox wrote:
>
> On Fri, 25 Aug 2000, John McKown wrote:
> >
> > However, after thinking about it a bit, I would guess that the sequence is
> > "locked" for the duration of the transaction. This would imply that all
> > other transactions which needed to access the sequence would be stalled
> > until this transaction ended.

No, the sequence does not remain locked for the duration of the
transaction. If that was the case sequences would be nearly useless for
most applications.

> > The above is just my guess.

It is always dangerous to guess with these things. :-)

> This 'locking' thing was what I was wondering about. If 'sequence
> locking' does actually take place,

It doesn't.

> On the other hand, holes in a sequence shouldn't be an issue for us so
> 'no locking' would be just fine.

The purpose of these sequences is to generate unique keys, therefore,
holes don't matter.

Joachim

--
work: joachima(at)realtimeint(dot)com (http://www.realtimeint.com)
private: joachim(at)kraut(dot)bc(dot)ca (http://www.kraut.bc.ca)

In response to

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Cedar Cox 2000-08-28 05:52:42 Re: JDBC problem
Previous Message Cedar Cox 2000-08-27 06:04:15 Re: JDBC problem