Subject | Re: [IB-Priorities] Isolation level implemetation |
---|---|
Author | Ann W. Harrison |
Post date | 2000-12-06T19:29:13Z |
Toni Martir wrote on the IB-Priorities list -
has some interesting architectural aspects.
with garbage collection. Most of the work has been done make read-only
read-committed transactions run as "pre-committed" so they don't affect
garbage collection. Read-write read-committed transactions could be
made not to affect the Oldest Active Transaction, but would require a
different mechanism. OAT is what you care about, OIT doesn't affect
garbage collection, only the number of transaction states every transaction
must carry around.
all tables in advance, you will not get deadlocks.
Serializing write transactions is not an option. Table locking is bad
enough - locking the entire database is serious overkill. The question
of record locking (and access path locking) has been raised many times
over the history of InterBase... it could be done, and with modern machines,
it could be used. On the other hand, it would be a lot of work ...
Regards,
Ann
www.ibphoenix.com
We have answers.
>I think adding new trasaction isolation levels to Interbase is a good thing:I'm responding on the Architecture list because this request
has some interesting architectural aspects.
>1- Less isolation level than read_commited/record_version,If I understand, you want a transaction mode that will not interfere
>- somethink like read uncommited, I know interbase has allways a commited
>record, but I want this isolation level to not affect the Oldest Interesting
>Transation. Read commited affect the OIT and if I left an open transaction
>for a long time, the garbage collection can not be done. The lowest
>isolation level will not affect the OIT.
with garbage collection. Most of the work has been done make read-only
read-committed transactions run as "pre-committed" so they don't affect
garbage collection. Read-write read-committed transactions could be
made not to affect the Oldest Active Transaction, but would require a
different mechanism. OAT is what you care about, OIT doesn't affect
garbage collection, only the number of transaction states every transaction
must carry around.
>2.- Serialized isolation level.If you use table stability on all read/write transactions and reserve
>- True serialized isolation level can be done by executing all write
>transactions one after another and all read transactions using the snapshot
>isolation level. Now, when I need this isolation level I use table
>reservation, but it's a tedious thing. At this isolation level Interbase can
>be the BEST database system compared to Oracle,SYBASE,SQL Server because the
>readers are never bloqued. If I use table stability my transaction can fail
>because dead locks.
all tables in advance, you will not get deadlocks.
Serializing write transactions is not an option. Table locking is bad
enough - locking the entire database is serious overkill. The question
of record locking (and access path locking) has been raised many times
over the history of InterBase... it could be done, and with modern machines,
it could be used. On the other hand, it would be a lot of work ...
Regards,
Ann
www.ibphoenix.com
We have answers.