Hi Jason and Ed,

> Dedicating a transaction to getting the generator value makes
> it work reliably. Therefore, even though it will be a bit of
> a performance hit, I think it's worth it to have the
> increased reliability.

I have not been following this all that closely, but I got the
impression that this was mainly an issue for embedded
installations - and, I would suggest, certain implementation
specific requirements that rely on generator values outside
the context of the database.


Given those very specific conditions I would not like to see
any significant performance hit being built into IBO that would
effect all implementations. So this begs a few questions:

- is the performance hit sigificant?

- are there other implications? Like the possibility that
you might trigger sweeps more often than expected or other
transaction age difference issues. Keep in mind that
generators may be called in very tight loops that go
through many thousands of iterations in a short time, so
the change may go through a LOT of transactions!

- could the problem be solved by the particular application
in other ways. That is: Why is an unsaved generator a
problem in this instance? (Bearing in mind that the
transaction that last used it is going to be rolled back.)

I am not suggesting that the problem isn't real, but I am
suggesting that the problem is not one that would effect most
applications. So if the problem is truly application specific
then so should the solution be. (Sorry Ed, but I assume you
would not expect all IBO applications world-wide to be slowed
down to solve a problem that only you had, even if it means you
have to change some of your own code?)

--
Geoff Worboys
Telesis Computing Pty Ltd