On Wednesday, April 1, 2015 at 2:12:40 PM UTC-7, somb...@gmail.com wrote: > - Crash-wise, are we talking about only the parent process crashing, or > are we talking about the child process crashing too?
I was talking just about the parent process. If the child process crashes then whether or not the transaction is durable depends on whether or not the parent received the commit message and processed it (otherwise we automatically abort any outstanding transactions). That behavior is unchanged. > 1. Device shutdown via the UI This should be fine, we will flush to disk before actually powering down. > 2. User pulls the battery. > 3. Hardware-shutdown via long-hold of the power button. > 4. Device runs out of power. These three cases may fail to flush the data to disk, and if so when we restart the transaction will be rolled back. > For 3: long-power-button-hold it seems like > depending on how extensively things are wedged, we could notice at say 6 > seconds that we're headed for a shutdown and try to trigger an fsync and > put a stop to new transactions. That sounds reasonable, assuming we get that notification at the gecko layer? I am not sure what kind of info we get when long-presses happen. > For 4: low-power, ideally there's just > a point that the device decides it's not safe to operate and shuts > itself down, and that's slightly before it would result in IndexedDB > badness. I don't know, but if it goes through normal shutdown then we will be fine. > My main question is what is a realistic risk model for power loss/crash > and are there mitigations we can put in place to reduce the risk to > users? > ... > The issue there is how long the IndexedDB window of vulnerability is. Flushing happens automatically after the database is idle (i.e. no active transactions) for 2 seconds at present. If the database never goes idle for that long then we continue to journal until the WAL size exceeds 20MB on desktop or 10MB on mobile. > - Wake lock interaction. Good question. I don't know of any testing in this area. IndexedDB does not hold an explicit wake lock at present. -bent _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
