| Subject | Re: [firebird-support] Multi-Version Consistent Read Question |
|---|---|
| Author | Helen Borrie |
| Post date | 2011-12-13T18:53:48Z |
At 03:39 AM 14/12/2011, Joey S. wrote:
-- Read Committed allows a client to see any changes committed after his transaction started. It is the responsibility of the client application to re-query the database to bring the remote view up to date.
-- Snapshot isolation (a.k.a. concurrency) keeps a persistent view of the database state as it was when your client's transaction started. Your client won't see changes committed by other transactions until his transaction commits.
-- Snapshot Table Stability (a.k.a. consistency) is like concurrency, but it also prevents any other transactions from committing work on the tables it is reading. On the other side of the coin, it is difficult for the consistency transaction to get write access to the tables if other transactions already have it. You wouldn't use this level often, if ever.
A transaction can *never* see pending writes for other transactions ("Dirty Read"). However, a pending write by one transaction will always cause a wait (if allowed by the lock resolution policy) or a lock conflict in any others that attempt to change the same rows.
How you "alert the user" to changes is up to you. The methods available vary according to what you are using to wrap the API - some drivers have extreme "smarts" to detect changes. Commonly, any such methods are based on trapping lock conflict exceptions, the nature of which will depend on both the isolation level and the lock resolution policy (wait/no wait).
Another approach is to use the Events mechanism in triggers, whereby an After Insert or Update or Delete trigger will issue a POST_EVENT when a state-changing operation is committed. Clients are set up to listen for these events and you write the application to respond in some appropriate way, e.g., re-query the tables (refresh) in Read Committed; or attempt to commit and refresh in Snapshot/concurrency.
./heLen
>Hello,What the client can "see" depends on the isolation level of the transaction. At all levels, your client's transaction sees its own changes. Those will not be visible to any other transaction until your client's transaction commits.
>
>I am researching methods to achieve high throughput for a learning chat
>application I am designing as a self-led student. I came across the
>Multiversion Control method of ACID and have a theoretical question: though
>it seems remote that a reader of data wouldn't get an "old" read what has
>been the experience and when this occurs what methods are available to
>alert the read user that data has been updated?
-- Read Committed allows a client to see any changes committed after his transaction started. It is the responsibility of the client application to re-query the database to bring the remote view up to date.
-- Snapshot isolation (a.k.a. concurrency) keeps a persistent view of the database state as it was when your client's transaction started. Your client won't see changes committed by other transactions until his transaction commits.
-- Snapshot Table Stability (a.k.a. consistency) is like concurrency, but it also prevents any other transactions from committing work on the tables it is reading. On the other side of the coin, it is difficult for the consistency transaction to get write access to the tables if other transactions already have it. You wouldn't use this level often, if ever.
A transaction can *never* see pending writes for other transactions ("Dirty Read"). However, a pending write by one transaction will always cause a wait (if allowed by the lock resolution policy) or a lock conflict in any others that attempt to change the same rows.
How you "alert the user" to changes is up to you. The methods available vary according to what you are using to wrap the API - some drivers have extreme "smarts" to detect changes. Commonly, any such methods are based on trapping lock conflict exceptions, the nature of which will depend on both the isolation level and the lock resolution policy (wait/no wait).
Another approach is to use the Events mechanism in triggers, whereby an After Insert or Update or Delete trigger will issue a POST_EVENT when a state-changing operation is committed. Clients are set up to listen for these events and you write the application to respond in some appropriate way, e.g., re-query the tables (refresh) in Read Committed; or attempt to commit and refresh in Snapshot/concurrency.
./heLen