Re: Share Mode Locking Problem...

Philippe Verdy <verdy_p@msn.com> wrote: : Whatever the choice, I think that a RDBMS could implement both strategies by : correctly using timestamps and by managing in each transaction if the : modification was applied in the database or not (to know where the original PostgreSQL, www.postgresql.org, does something like that. When it is going to do modify query, it gets a transaction ID, and for every changed row, it makes a copy and puts the transaction id on the old row as superceeded, and on the new row. When a transaction commits, it just marks the transaction id as committed in a central table. In a rollback, the transaction id is never marked committed, the old data is still seen as valid, and the aborted one is seen as invalid because it does not have a committed transaction id. You must vacuum the database regularly to clean out the old rows. -- Bruce Momjian | 830 Blythe Avenue root@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)