Subject | Re: [ib-support] Generated ID and constraints |
---|---|
Author | Ann W. Harrison |
Post date | 2001-12-19T19:28:09Z |
At 05:16 PM 12/19/2001 +0000, Douglas Tosi wrote:
NEW.ID = GEN_ID(GEN, 0);
and in the After insert trigger:
DummyVar = GEN_ID(GEN, 1);
I'm not sure if this method works ok on a highly concurrent environment...
Unfortunately, it will work badly - there will be duplicates and
skipped numbers. The issue of "lost" generator values has been
discussed on this list and the old mers list and the even older
InterBase list. The upshot is this. There are a number of ways
to insure that all id values are used, but they are all transaction
based. Transaction based identifiers are a bottleneck at best and
lead to frequent deadlocks at worst. There are ways to reduce the
bottleneck, but they tend to lead to complicated code. Generators
are very cheap to use and can not deadlock. However if an operation
fails, they "lose" values.
Regards,
Ann
www.ibphoenix.com
We have answers.
> If any constraint causes an exeption user get error message but myIn the Before Insert trigger, do:
> generator already increased.
NEW.ID = GEN_ID(GEN, 0);
and in the After insert trigger:
DummyVar = GEN_ID(GEN, 1);
I'm not sure if this method works ok on a highly concurrent environment...
Unfortunately, it will work badly - there will be duplicates and
skipped numbers. The issue of "lost" generator values has been
discussed on this list and the old mers list and the even older
InterBase list. The upshot is this. There are a number of ways
to insure that all id values are used, but they are all transaction
based. Transaction based identifiers are a bottleneck at best and
lead to frequent deadlocks at worst. There are ways to reduce the
bottleneck, but they tend to lead to complicated code. Generators
are very cheap to use and can not deadlock. However if an operation
fails, they "lose" values.
Regards,
Ann
www.ibphoenix.com
We have answers.