That's good Geoff,
many thanks,

Nico Callewaert

-----Oorspronkelijk bericht-----
Van: Geoff Worboys [mailto:geoff@...]
Verzonden: dinsdag 19 juni 2001 3:53
Aan: IBObjects@yahoogroups.com
Onderwerp: Re: [IBO] Transaction isolation

> Did I change it in a good way, or has some IBO huru out
> there better ideas ?

"huru" - must be talking about me ;-)

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
have made.

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
results.


HTH

Geoff Worboys
Telesis Computing




Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/