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)
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 |