- From: Joran Greef <joran@ronomon.com>
- Date: Thu, 4 Aug 2011 09:28:02 +0200
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: public-webapps@w3.org
> 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