From: [email protected] [mailto:[email protected]] On
Behalf Of Andrei Popescu
Sent: Monday, July 12, 2010 5:23 AM
Sorry I disappeared for a while. Catching up with this discussion was an
interesting exercise...there is no particular message in this thread I can
respond to, so I thought I'd just reply to the last one. Overall I think the
new proposal is shaping up well and is being effective in simplifying
scenarios. I do have a few suggestions and questions for things I'm not sure I
see all the way.
READ_ONLY vs READ_WRITE as defaults for transactions:
To be perfectly honest, I think this discussion went really deep over an issue
that won't be a huge deal for most people. My perspective, trying to avoid
performance or usage frequency speculation, is around what's easier to detect.
Concurrency issues are hard to see. On the other hand, whenever we can throw an
exception and give explicit guidance that unblocks people right away. For this
case I suspect it's best to default to READ_ONLY, because if someone doesn't
read or think about it and just uses the stuff and tries to change something
they'll get a clear error message saying "if you want to change stuff, use
READ_WRITE please". The error is not data- or context-dependent, so it'll fail
on first try at most once per developer and once they fix it they'll know for
all future cases.
Dynamic transactions:
I see that most folks would like to see these going away. While I like the
predictability and simplifications that we're able to make by using static
scopes for transactions, I worry that we'll close the door for two scenarios:
background tasks and query processors. Background tasks such as synchronization
and post-processing of content would seem to be almost impossible with the
static scope approach, mostly due to the granularity of the scope specification
(whole stores). Are we okay with saying that you can't for example sync
something in the background (e.g. in a worker) while your app is still working?
Am I missing something that would enable this class of scenarios? Query
processors are also tricky because you usually take the query specification in
some form after the transaction started (especially if you want to execute
multiple queries with later queries depending on the outcome of the previous
ones). The background tasks issue in particular looks pretty painful to me if
we don't have a way to achieve it without freezing the application while it
happens.
Implicit commit:
Does this really work? I need to play with sample app code more, it may just be
that I'm old-fashioned. For example, if I'm downloading a bunch of data form
somewhere and pushing rows into the store within a transaction, wouldn't it be
reasonable to do the whole thing in a transaction? In that case I'm likely to
have to unwind while I wait for the next callback from XmlHttpRequest with the
next chunk of data. I understand that avoiding it results in nicer patterns
(e.g. db.objectStores("foo").get(123).onsuccess = ...), but in practice I'm not
sure if that will hold given that you still need error callbacks and such.
Nested transactions:
Not sure why we're considering this an advanced scenario. To be clear about
what the feature means to me: make it legal to start a transaction when one is
already in progress, and the nested one is effectively a no-op, just refcounts
the transaction, so you need equal amounts of commit()'s, implicit or explicit,
and an abort() cancels all nested transactions. The purpose of this is to allow
composition, where a piece of code that needs a transaction can start one
locally, independently of whether the caller had already one going.
Schema versioning:
It's unfortunate that we need to have explicit elements in the page for the
versioning protocol to work, but the fact that we can have a reliable mechanism
for pages to coordinate a version bump is really nice. For folks that don't
know about this the first time they build it, an explicit error message on the
schema change timeout can explain where to start. I do think that there may be
a need for non-breaking changes to the schema to happen without a "version
dance". For example, query processors regularly create temporary tables during
sorts and such. Those shouldn't require any coordination (maybe we allow
non-versioned additions, or we just introduce temporary, unnamed tables that
evaporate on commit() or database close()...).
Thanks
-pablo
