Geoff,

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

My sense is that there shouldn't be a client-side dependency on getting
generator values for a long-running series of things. A good developer would
always be able to avoid doing it this way. The call to the database to get
the generator itself would be inefficient and worth avoiding so adding a
transaction to that would not likely be a significant impact to a properly
developed application. This is more or less intended for use in an
interactive application where things are being worked with in small bits at
a time.

I could add a property CrashProofGeneratorCalls so that Ed could configure
his application to be more robust and leave others with the default
behavior. I could even make it be CrashProof when connected to an embedded
server and otherwise leave it as it has always been.

Jason