|Subject||Re: [IBO] Transaction isolation|
> Did I change it in a good way, or has some IBO huru out"huru" - must be talking about me ;-)
> there better ideas ?
I am not sure if what you have done is truly necessary.
Transaction isolations of tiCommitted and tiConcurrency have more to
do with visibility of changes rather than blocking of updates.
(tiConsistency will block changes and should be avoided.)
Interbase uses optimistic updates that will only fail if they conflict
with optimistic updates from another transaction (presuming that
tiConsistency transactions are not involved). It does not matter
whether either transaction is using tiCommitted or tiConcurrency.
The difference is that a tiCommitted transaction will be able to see
changes made by other transactions as soon as they are commited. A
tiConcurrency transaction continue to see the old version of the data
(as it was when the transaction started) until the transaction is
closed and restarted.
So, to use your example...
If the changes applied via TransactionA may somehow impact on what is
displayed via TransactionB, then you can avoid having changes made
visible by using tiConcurrency - as you have done. However if you
want the changes to be visible, or if there is no impact, then there
is no reason for having a separate transaction.
Generally I recommend tiConcurrency for use with reports. For user
interactive purposes tiCommitted is generally a better choice - since
the user normally expects immediate feedback about changes that they
A good example of the need for tiConcurrency is a report like...
SELECT * FROM SomeTable - is used to produce a list for printing
SELECT * FROM SomeProcedure - is called to produce summary data at
the end of the report.
If this report was run using a tiCommitted transaction, and some other
user committed changes while the report was running, then the summary
data produced by SomeProcedure may not be consistent with what was
listed from SomeTable. By using a tiConcurrency transaction you can
ensure any changes made by other transactions while this transaction
is still active will not be visible and so produce predictable