Subject Re: [firebird-support] Re: Correct Way?
Author David Johnson
When a transaction is rolled back, its token must be inserted into a
placeholder "void" record. Instead of a simple rollback, the rollback
operation must consist of rollback, start trans, insert "void" record,
commit.

One of our service vendors does this for missing tokens.

On Wed, 2004-10-27 at 06:17, Bogusław Brandys wrote:
>
> Helen Borrie wrote:
> > At 03:41 AM 27/10/2004 +0000, you wrote:
> >
> >
> >
> >>Hi
> >>--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
> >>wrote:
> >>
> >>
> >>>Yes: get the generator value BEFORE it is to be used. Generators
> >>
> >>execute
> >>
> >>>outside of all transaction contexts and a value can not be generated
> >>>twice. Depending on how your application interface works, you can
> >>
> >>do this
> >>
> >>>one of two ways, both simple:
> >>
> >>I am curious.
> >>
> >>In a multi user environment where a generator generates a two or more
> >>values (for two or more separate transactions), if a prior value is
> >>rolled back, leaving a later value in use in the table (thinking along
> >>the lines of value 1, 2, 3 etc). Would (could?) the genrerator reuse
> >>ie regenerate a now missing ie unused value.
> >>
> >>For example...
> >>
> >>user 1 begins a transaction and is issued value 101 by the generator.
> >>user 2 begins a transaction and is issued value 102 by the generator.
> >>user 3 begins a transaction and is issued value 103 by the generator.
> >>
> >>If user 3 commits value 103, then user 1 rolls back the transaction
> >>effectively not using value 101, would the generator "know" that it
> >>can use value 101 and use it before generating value 104?, or does all
> >>of this only operate on an incremental basis?
> >>
> >>Perhaps this is dependant on user needs?
> >
> >
> > Nope. As I said, generators generate right outside ALL transaction
> > contexts. Once a value is generated it can't be generated again. It's not
> > related to any transaction context that requested it. Generator numbers
> > are not "recycled" by the engine.
> >
> > Unless, of course, you do something really stoopid, like running SET
> > GENERATOR.
> >
> > ./hb
> >
>
> Helen
>
> I use now method 2 as described by wuiler , getting unbroken, auditable
> series of document numbers (yes I read "An Auditable Series of Numbers"
> from IbObjects page long time ago) from single updated value stored in
> database and updated each time when new document is created.
> I know it causes a bottleneck but reusing old numbers is no option for
> me. I must be sure that numberation is continuous.Is it really possible
> without other users waiting to my transaction finish to get new number ?
> Now I doubt if it can be done in SQL multiuser database becouse it
> impact performance of any database client application.
>
>
> Regards
> Bogusław Brandys
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>