Subject | Re: [Firebird-Architect] Supported transaction isolation levels? |
---|---|
Author | Thomas Steinmaurer |
Post date | 2005-04-05T19:55:50Z |
Hi Dmitry,
on a "full" MVCC implementation or is it something comparable to
Oracle's MVRC (Multi-Version Read Consistency), which is AFAIK a bit
different.
Cheers,
Thomas
> TS> The weird thing now is that the MySQL folks claim that the InnoDB tableDo you remember, whether the snapshot isolation level in Yukon is based
> TS> type supports ACID-compliant transactions with all four isolation levels
> TS> and even support of the MVCC model. Well, this is off-topic here, but I
> TS> do find it somewhat strange.
>
> maybe. Firebird architects up to now struggles against Dirty Read,
> while it can be implemented in MGA extending read_committed
> no_rec_version isolation mode. But, implementing Repeatable Read
> exactly as in standard could be tricky, since it allows fanthom reads.
>
> I.e. itself versioning engine can easlily support Dirty Read,
> Read Committed and Snapshot isolation levels (Snapshot is stronger
> than Repeatable Read). But, Serializable isolation needs something
> like "serial transation pool" which I think doesn't have anything
> related to MGA or any other locking scheme.
>
> You may know, that new MS SQL version (Yukon) will also use
> versioning, behaving like IB/FB versioning. But, some people
> have suspects about its functioning, because of internal
> MVCC implementation in Yukon (there was a big article about
> versioning in Yukon in one russian magazine, I'm not sure
> this article was translated into english).
on a "full" MVCC implementation or is it something comparable to
Oracle's MVRC (Multi-Version Read Consistency), which is AFAIK a bit
different.
Cheers,
Thomas