RE: [IndexedDB] Transaction Auto-Commit

On Thursday, August 04, 2011 11:02 AM, Jonas Sicking wrote:
> On Aug 4, 2011 12:28 AM, "Joran Greef" <joran@ronomon.com> wrote:
> >
> > > 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.
The two main reasons is to prevent people from performimg slow running tasks, such as network activities, while keeping the transition open, and to prevent people from accidentally forgetting to commit a transaction, for example if a exception is thrown.
> > > 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.
>
> I'd be open to allowing read transactions which are started after a write transaction to see the before-write database contents. Would definitely want input from Microsoft and Google first though. There is also a question if this should be opt-in or default behavior.
> My gut feeling is to leave this for version 2. Though that of course removes the ability to make it default behaviour.

Microsoft would like to push this change to v2 and try to get the v1 spec to Last Call soon so we can start getting some adoption on this technology.

Israel

Received on Tuesday, 16 August 2011 17:52:41 UTC