Re: [IndexedDB] Transaction Auto-Commit

On Mon, Aug 15, 2011 at 11:23 PM, Shawn Wilsher <me@shawnwilsher.com> wrote:
> On 8/3/2011 10:33 AM, Jonas Sicking wrote:
>>
>> IndexedDB does however not allow readers to start once a writing
>> transaction has started. I thought that that was common behavior even
>> for MVCC databases. Is that not the case? Is it more common that
>> readers can start whenever and always just see the data that was
>> committed by the time the reading transaction started?
>
> This is one of the many benefits of MVCC (but Mozilla's implementation
> cannot provide this).

I can definitely say that InnoDB (now MySQL's default storage engine)
normally allows lockless reads even if a write lock is being held on
the relevant rows.  A SELECT will not normally block or be blocked by
any other reads or writes, and will always read some committed value
regardless of what uncommitted changes have been made.  This is
affected by the transaction isolation level and by the optional IN
SHARE MODE and FOR UPDATE flags you can pass to SELECT, plus there are
other details like that some SELECTs are always FOR UPDATE (like
INSERT ... SELECT), but that's the basic picture.  Of course, a
statement that *writes* to a row will take out an exclusive lock and
hold it until the transaction is committed, but that only blocks other
locking statements such as writes.  Also, obviously there are some
locks being taken behind the scenes here so that different threads
don't trample each other in various exciting ways, but they aren't
logically exposed to the database user.

My impression is that all this is standard for MVCC databases.

Received on Tuesday, 16 August 2011 14:57:10 UTC