Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
Also, what should we do when you enqueue a setVersion transaction and then close the database handle? Maybe an ABORT_ERR there too? Yeah, that'd make sense to me. Just like if you enque any other transaction and then close the db handle. We don't abort transactions that are already in progress when you call db.close()... We just set a flag and prevent further transactions from being created. -Ben
Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
On Thu, Feb 17, 2011 at 11:02 AM, ben turner bent.mozi...@gmail.com wrote: Also, what should we do when you enqueue a setVersion transaction and then close the database handle? Maybe an ABORT_ERR there too? Yeah, that'd make sense to me. Just like if you enque any other transaction and then close the db handle. We don't abort transactions that are already in progress when you call db.close()... We just set a flag and prevent further transactions from being created. Doh! Of course. If the setVersion transaction has started then we should definitely allow it finish, just like all other transactions. I don't have a strong opinion on if we should let the setVersion transaction start if it hasn't yet. Seems most consistent to let it, but if there's a strong reason not to I could be convinced. / Jonas
Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
On Thu, Feb 17, 2011 at 11:12 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 17, 2011 at 11:02 AM, ben turner bent.mozi...@gmail.com wrote: Also, what should we do when you enqueue a setVersion transaction and then close the database handle? Maybe an ABORT_ERR there too? Yeah, that'd make sense to me. Just like if you enque any other transaction and then close the db handle. We don't abort transactions that are already in progress when you call db.close()... We just set a flag and prevent further transactions from being created. Doh! Of course. If the setVersion transaction has started then we should definitely allow it finish, just like all other transactions. I don't have a strong opinion on if we should let the setVersion transaction start if it hasn't yet. Seems most consistent to let it, but if there's a strong reason not to I could be convinced. What if you have two database connections open and both do a setVersion transaction and one calls .close (to yield to the other)? Neither can start until one or the other actually is closed. If a database is closed (not just close pending) then I think we need to abort any blocked setVersion calls. If one is already running, it should certainly be allowed to finish before we close the database. J
RE: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Thursday, February 17, 2011 11:51 AM On Thu, Feb 17, 2011 at 11:12 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 17, 2011 at 11:02 AM, ben turner bent.mozi...@gmail.com wrote: Also, what should we do when you enqueue a setVersion transaction and then close the database handle? Maybe an ABORT_ERR there too? Yeah, that'd make sense to me. Just like if you enque any other transaction and then close the db handle. We don't abort transactions that are already in progress when you call db.close()... We just set a flag and prevent further transactions from being created. Doh! Of course. If the setVersion transaction has started then we should definitely allow it finish, just like all other transactions. I don't have a strong opinion on if we should let the setVersion transaction start if it hasn't yet. Seems most consistent to let it, but if there's a strong reason not to I could be convinced. What if you have two database connections open and both do a setVersion transaction and one calls .close (to yield to the other)? Neither can start until one or the other actually is closed. If a database is closed (not just close pending) then I think we need to abort any blocked setVersion calls. If one is already running, it should certainly be allowed to finish before we close the database. This sounds reasonable to me (special case and abort the transaction only for blocked setVersion transactions). We should capture it explicitly on the spec, it's the kind of little detail that's easy to forget. -pc
Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
On Thu, Feb 17, 2011 at 3:58 PM, Pablo Castro pablo.cas...@microsoft.comwrote: From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Thursday, February 17, 2011 11:51 AM On Thu, Feb 17, 2011 at 11:12 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 17, 2011 at 11:02 AM, ben turner bent.mozi...@gmail.com wrote: Also, what should we do when you enqueue a setVersion transaction and then close the database handle? Maybe an ABORT_ERR there too? Yeah, that'd make sense to me. Just like if you enque any other transaction and then close the db handle. We don't abort transactions that are already in progress when you call db.close()... We just set a flag and prevent further transactions from being created. Doh! Of course. If the setVersion transaction has started then we should definitely allow it finish, just like all other transactions. I don't have a strong opinion on if we should let the setVersion transaction start if it hasn't yet. Seems most consistent to let it, but if there's a strong reason not to I could be convinced. What if you have two database connections open and both do a setVersion transaction and one calls .close (to yield to the other)? Neither can start until one or the other actually is closed. If a database is closed (not just close pending) then I think we need to abort any blocked setVersion calls. If one is already running, it should certainly be allowed to finish before we close the database. This sounds reasonable to me (special case and abort the transaction only for blocked setVersion transactions). We should capture it explicitly on the spec, it's the kind of little detail that's easy to forget. Captured in http://www.w3.org/Bugs/Public/show_bug.cgi?id=12114
[IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
On Wed, Feb 9, 2011 at 4:30 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 9, 2011 at 4:03 PM, Jeremy Orlow jor...@chromium.org wrote: Gotcha. Does this mean that _every_ async request will fire an onerror or onsuccess? I guess I had forgotten about that (and assumed it was that it'd fire either 0 or 1 times.) Yes. That's the idea. It's always nice to be able to rely on that you'll *always* get one of the two callbacks. That way you can put cleanup code in there and be sure that it always runs. Will the IDBRequest always fire before the IDBTransaction's abort/complete event fires? (It seems like it should.) Also, what should we do when you enqueue a setVersion transaction and then close the database handle? Maybe an ABORT_ERR there too? J
Re: [IndexedDB] More questions about IDBRequests always firing (WAS: Reason for aborting transactions)
On Wed, Feb 16, 2011 at 8:40 PM, Jeremy Orlow jor...@chromium.org wrote: On Wed, Feb 9, 2011 at 4:30 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Feb 9, 2011 at 4:03 PM, Jeremy Orlow jor...@chromium.org wrote: Gotcha. Does this mean that _every_ async request will fire an onerror or onsuccess? I guess I had forgotten about that (and assumed it was that it'd fire either 0 or 1 times.) Yes. That's the idea. It's always nice to be able to rely on that you'll *always* get one of the two callbacks. That way you can put cleanup code in there and be sure that it always runs. Will the IDBRequest always fire before the IDBTransaction's abort/complete event fires? (It seems like it should.) I agree. Also, what should we do when you enqueue a setVersion transaction and then close the database handle? Maybe an ABORT_ERR there too? Yeah, that'd make sense to me. Just like if you enque any other transaction and then close the db handle. / Jonas
