On Wed, Apr 1, 2015, at 03:02 PM, ben turner (bent) wrote: > If a crash or power loss occurs at just > the right moment then the transaction will be lost/rolled back. It should > still be impossible to ever see database corruption though. This will > mean faster delivery of "complete" events, and more closely aligns with > the performance vs. stability tradeoffs other browser vendors have > chosen.
Can you clarify the risk profile a little more? Specifically: - Crash-wise, are we talking about only the parent process crashing, or are we talking about the child process crashing too? - For power loss for B2G on mobile, battery-powered devices, the following sources of power loss seem to come to mind: 1. Device shutdown via the UI 2. User pulls the battery. (More likely, QA pull the battery :) 3. Hardware-shutdown via long-hold of the power button. (Because of apparent device lockup, user is QA, or accidental triggering due to pockets/device placement.) 4. Device runs out of power. It seems like we can probably avoid the problems during 1: normal device shutdown. Is it your/anyone's understanding that gecko and IndexedDB will get a chance to cleanly shutdown and an fsync will happen? I don't think we can do anything for 2: battery pulled (although if there's a back-cover-sensor...) 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. 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. 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 best example I have of this is when a QA tester was adding a contact to the contacts app and then pulling the battery on the device. This did find real bugs, but in terms of use-cases to engineer for, I don't think it's a valid use-case to add a contact and then immediately pull the battery. I do think it's a valid use-case to add a contact and then shutdown the device via the UI once the user has seen implied visual confirmation that the operation has completed. (I think in the case of that bug, the window of vulnerability was shockingly long.) On the flip side, desktop users on mains power are usually going to have a failure model that looks like 2: QA pulling the battery when the mains go out. But at the same time, it's understood that if your computer loses power, you very well may lose some work and a UPS may be advisable on unstable power. The issue there is how long the IndexedDB window of vulnerability is. Andrew _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
