Re: [IndexedDB] Transaction Auto-Commit

> On 03 Aug 2011, at 7:33 PM, Jonas Sicking wrote:
> 
>>>> "Note that reads are also blocked if the long-running transaction is a READ_WRITE transaction."
>> 
>> Is it acceptable for a writer to block readers? What if one tab is downloading a gigabyte of user data (using a workload-configurable Merkle tree scheme), and another tab for the same application needs to show data?
> 
> This is exactly why transactions are auto-committing. We don't want
> someone to start a transaction, download a gigabyte of data, write it
> to the database, and only after commit the transaction. The
> auto-committing behavior forces you to download the data first, only
> then can you start a transaction to insert that data into the
> database.

If someone were syncing a gigabyte of data using a Merkle tree scheme they would probably not consider using a single transaction to persist the data nor would they find it necessary. Rather the point was made to emphasize that a write-intensive task may take place where many write transactions are required, one after the other. For instance, in the previous example, a gigabyte of data may likely consist of a million 1KB text objects, or 250,000 4KB objects, each of which may require a write transaction to update a few parts of the database. Any implementation of IDB where writers blocked readers would perform poorly in this case.

But all of this is orthogonal to the question of auto-commit. Are there other reasons in favor of auto-committing transactions? I'm not sure that library writers stand to gain from it, and it forces one to use other methods of concurrency control to match the semantics of server-side databases.

> IndexedDB allows MVCC in that it allows writers to start while there
> are still reading transactions running. Firefox currently isn't
> implementing this though since our underlying storage engine doesn't
> permit it.
> 
> 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?

If your database supports MVCC, then by definition there is no reason for writers to block readers.

Received on Thursday, 4 August 2011 07:34:48 UTC