[whatwg] Database API: transaction can get help open too long

[Scott Hess]

On Fri, May 23, 2008 at 9:48 AM, Aaron Boodman <aa at google.com> wrote:
> I noticed one unfortunate thing about the new Database API. Because
> the executeSql() callback holds open the transaction, it is easy to
> accidentally do intensive work inside there and hold open the
> transaction too long. A common mistake might be to do a big select and
> then hold open the transaction while the UI is updated. This could
> hold open the tx maybe an extra couple hundred ms. A bigger problem
> would be to do synchronous XHR (for example, in workers). This could
> hold open the tx for seconds.
>
> The right place to do work like this is in transaction()'s success
> callback. But because the resultsets aren't easily accessible there, I
> think authors are more likely to do work in executeSql()'s success
> callback and use transaction()'s success callback less frequently.
>
> Off hand about the best solution I can think of to this problem is to
> have some sort of state on the transaction object that gathers the
> results.
>
> This is not very satisfying though. Does anyone have a better idea? Or
> think this is not a big enough concern to worry about?

I think this is like async-versus-sync.  It's very important to allow
people to do things the right way, and it's very nice to make it easy
to do things the right way, but you shouldn't force people into a
particular approach unless that approach is pretty unassailable, or
the alternative is simply worse.  I can't see any way to buffer result
sets until the end of the transaction without losing a fair bit of
generality (because the API can't make assumptions, so would have to
just buffer everything).

I think the only way you can really make it better is to put something
like an executeSql() function directly on Database objects, which
could shift the success callback entirely outside the transaction
scope.  I think that would reasonably match server-side SQL use (you
either send a bare SELECT with implicit transaction, or use explicit
BEGIN/END to group things which must be consistent).

-scott