- From: Scott Hess <shess@google.com>
- Date: Tue, 27 May 2008 14:15:53 -0700
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
Received on Tuesday, 27 May 2008 14:15:53 UTC