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.

What does a full refresh exactly mean? Which IBO method should have been
called here or is it a matter of closing and re-opening?

Honestly, I'm not sure, but I guess I wouldn't expect to see
non-committed changes by the IB_TransForUpdate in the read transaction.
So, if the read transaction is working as read committed, then it simply
will see committed changes.

I'm not sure either, if I would like to see non-committed changes anyway.


--
With regards,
Thomas Steinmaurer

* Firebird Foundation Committee Member
http://www.firebirdsql.org/en/firebird-foundation/

* Upscene Productions - Database Tools for Developers
http://www.upscene.com/

* My Blog
http://blog.upscene.com/thomas/index.php