"Doug Chamberlin" wrote in message

> Re-using a connection and a statement is quite common and efficient.
> That's what connection pooling is all about.

I appreciate your response!

> Re-using a transaction (using one and not committing it for a long time)
> is not. This will eventually cause you big problems.
>
> Try changing your test to start a transaction and commit it each time.
> Should run quite fast.

I would definately do this if I were inserting, updating or deleting.
But
is a new transaction and commit necessary for read-only access mode /
read
commited isolation? In my testing, creating a new transaction and
statement
was noticably slower. In both cases, I did not experience memory
leaks and
the data returned was accurate. But if it is required to create a
transaction and commit it for read-only transactions, I will do it.

Here is some interesting info from Harrison you may find of interest:

"a read-only, read committed transaction doesn't block garbage
collection,
but does collect garbage as it finds it"

"a read-only, read committed transaction can remain open indefinately
without causing the OAT (oldest active transaction) to stick."

And from Borrie:

"a read-only transaction has no potential to create its own garbage."

"read committed isolation is not interested in back versions. Unlike
other
transactions, it is not an interesting transaction once it has been
committed or rolled back"

Flipping through Borrie's transaction sections in her Firebird Book was
extremely helpful but I still do not fully understand.

Thank you