Re: [IndexedDB] Transaction Auto-Commit

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.