This project has moved and is read-only. For the latest updates, please go here.

Atomic Commits

Nov 3, 2011 at 9:03 AM


One of the issues that we need to consider is the integrity of the database in the scenarios where the store is being written to and the browser/application crashes.  Sterling doesn't seem to support atomic commits (I've seen the suggestion on Rollback / Pseudo-Transaction Support in the User Guide), but if the application crashes half-way through a write, it can potentially corrupt the DB making it impossible to use.  Our uses will be downloading quite a lot of data over time through a sychronization mechanism and the possibility of the DB becoming corrupt is a serious concern for us.  So my question, does Sterling support atomic commits out-of-the-box?  If not, is that a feature being considered for the future and also what current strategies are there for handling these kinds of scenarios.  The only strategy I can think of is a regular backup schedule that will allow a restore of data in the this scenario.  What other options can we consider?


Nov 3, 2011 at 10:11 PM


Completely understand your concerns. Unfortunately Sterling does not support atomic transactions. While some strategies have been discussed I do not have a timeline currently.