It is also possible to get a deadlock while reading if you change the
RecVersion property along with the tiCommitted isolation (can't remember if
true or false does it). What this can do is force that you are always
reading the most current committed record. So, if there is a record in there
that isn't committed yet it will block the reading because it is unable to
deliver the most recent committed record. Thus a deadlock condition takes
place. This is something that you should avoid in all interactive
applications. I think all reports should be run in tiConcurrency
transactions. It's purely a matter of data integrity. Be sure to start and
end the transaction immediately upon running the report. IBO does no
automatic cleanup of something you asked to be a snapshot.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Geoff Worboys" <geoff@...>
To: <IBObjects@yahoogroups.com>
Sent: Friday, March 23, 2001 1:03 AM
Subject: Re: [IBO] Transaction question


> > My question now is, could a DEADLOCK appear in such a situation,
> > when a user is only READING information from a readonly
> > transaction ?
>
> Not from that user. But presumably your system will support multiple
> users, in which case a deadlock can still occur when updates from
> multiple users conflict.
>
> Oh, actually it can appear. If you use Isolation=tiConsistency on
> either transaction you effectively prevent updates to all records that
> it reads. For this reason Isolation=tiConsistency is not recommended
> unless this is exactly what you want to happen.
>
> HTH
>
> Geoff Worboys
> Telesis Computing