Subject Re: firebird deadlock vs isc_tpb_wait/etc. issue, or ?
Author learntrade
1)Aren't firebird <v2 generators 32-bit?

2)Are firebird >=v2 generators/sequences going to be(support?)
>32-bit? (I read through some of the v2rc5 release notes, but don't
recall - will look again.)
(It's not beyond the realm of possibility that my needs would exceed
32-bits in the application under development. My record declared the
columns as "bigint", which I think (?) is supposed to be 64-bit.
While its likely sequence/generator support would reach 64-bits before
I "needed" it, that would of course incur additional effort when the
time came to upgrade to the version that had it, and implement, test,
and modify all related/affected areas. That could be mitigated
somewhat by having the procedures return a bigint for the generator
value. But still, I've found otherwise unnecessary change in a
production environment to be avoided if possible.)

3)I was trying to see if I understood how "things worked." I'm still
a little unclear here, but I'm currently thinking I understand how
they're supposed to work, but they aren't working that way.

4)Slowness isn't so much a concern in this case - I'm unlikely to
exert the load my simple test produces in production. But,
correctness, is of course, a significant concern.

5)I can simply code for the deadlock exception and retry. BUT, if its
an issue in firebird (i.e. my code as presented doesn't contain an
error), then its presence (while everyone can code for it) reduces the
throughput possible with firebird, as it will incur round-trip
latencies (even most likely across network connections in a large
multi-client environment). And of course, its most likely to show up
when loaded, when people would be trying to determine possible
throughput/loads supported. (In my research efforts prior to original
post for this issue, I saw a post by Jim Starkey (?sp) [architecture
list?] that suggested transaction load support in firebird may
currently be a concern, at least in comparison to the "big guys.")

Thanks, and Regards.

--- In, "Ann W. Harrison"
<aharrison@...> wrote:
> learntrade wrote:
> >
> > I am basically trying to update a value (similar to a generator), and
> > return that "next" value to serve multiple requesting clients (only
> > one value to one client at a time).
> Err, that's exactly why generators were created. It's a hard problem,
> made somewhat harder (in my opinion) by the matrix of transaction
> modes and options. The easy answer is to use the facility provided,
> i.e. generators. If you're worried about portability, the SQL standard
> committee has endorsed "sequences" which are much like generators and
> Firebird 2 implements the standard syntax.
> Even if you get your procedure to work, it will be MUCH slower than
> generators.
> Regards,
> Ann