- From: Aaron Boodman <aa@google.com>
- Date: Fri, 23 May 2008 09:48:19 -0700
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? - a
Received on Friday, 23 May 2008 09:48:19 UTC