- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 18 May 2010 15:31:40 -0700
- To: Nikunj Mehta <nikunj@o-micron.com>
- Cc: Jeremy Orlow <jorlow@chromium.org>, Shawn Wilsher <sdwilsh@mozilla.com>, public-webapps WG <public-webapps@w3.org>
On Tue, May 18, 2010 at 2:57 PM, Nikunj Mehta <nikunj@o-micron.com> wrote: > > On May 18, 2010, at 2:33 PM, Jeremy Orlow wrote: > > On Tue, May 18, 2010 at 9:36 PM, Shawn Wilsher <sdwilsh@mozilla.com> wrote: >> >> On 5/18/2010 1:02 PM, Nikunj Mehta wrote: >>> >>> A database connection that locks the entire database cannot be opened if >>> there is another database connection that locks at least one database >>> object, e.g., an index or object store. >> >> So basically, as long as some connection holds a database lock, you won't >> be able to do any upgrade. > > Sure, but this is true of Jonas' proposal as well. > > But to me it is a no-op. The spec already does what Jonas is proposing - > lock out users when an upgrade is in progress and wait to start an upgrade > if a user is using the application. Note that in our proposal, having a database open does not hold any locks. It simply holds metadata (such as objectStore and index names) in memory. It is totally ok for the application to open the database when the user initially loads the page, and never close it until the user leaves the page. In fact, I would encourage users to do this since it allows for reading data using a single level asynchronous callbacks, and so makes for very readable code. Because our proposal is incompatible with the versioning mechanism that the spec uses, I would propose that we first decide on if mozillas proposal should be accepted before we decide on what versioning mechanism we should use. / Jonas
Received on Tuesday, 18 May 2010 22:58:26 UTC