Thomas,

> Hello Jason,
>
> >> One thing is, if you only read data, then use a read-only transaction.
> >> In combination with the read committed isolation level, you are in a
> >> transaction mode with very low overhead and OIT/OAT won't get stuck as
> >> well, even for long runners.
> >
> > It might also be helpful to make use of a relatively new feature I added
> to
> > IBO that enables you to separate your transaction handling between two
> > physical transactions. One is for reading only and the other is for your
> > updates and individual record synchronizations. The new property is
> called
> > IB_TransForUpdate.
>
> Thanks for letting me know.

This property was requested by Carlos Cantu so that when using cached
updates it was possible to have different transaction isolation and behavior
between the fetching of records and the processing of the updates. I chose
to implement it the way I did so that you could also take advantage of this
through other more direct means.

Because Firebird has enhanced the transaction behavior internally such that
ReadCommitted and ReadOnly transactions do not stuff up garbage collection
and bloat the internal transaction buffers, it is now possible to have all
fetching be performed through such a transaction while all of your updates,
etc. are performed using a transaction that can fully commit without
interfering with open cursors that have not yet fetched all records in your
dataset.

Thus, between the enhancements in Firebird and the enhancements in IBO, you
can now have full fluidity and efficiency in interacting with your data such
that large datasets and updates are no longer in conflict.

Also, the most difficult aspect of this is keeping records in sync. No other
component set resolves this for you (at least not to my knowledge) to get
record-level synchronization when you are using different transactions for
reading and writing. IBO automatically detects when a transaction for
updating is active and it distinguishes record synchronization from normal
fetching and handles the record synchronization via the transaction being
used for updates so that you will always get the latest version of records
when reading them.

There is only one awkward aspect left I have not fully decided how to deal
with. When doing a full refresh of a dataset that has an active
IB_TransForUpdate transaction, it will not see the non-committed changes.
The resolution could be to cause the refresh to occur within the
IB_TransForUpdate context or to raise an exception. I'd be interested in
hearing what others think on this subject.

Thanks,
Jason