We are developing an RetailPOS .net (windows) application.
One of the customer asks 'What will happen to current data being processed in the application when a power went off suddenly?', 'Will the application able to recover the unsaved data?'
I am wondering, how this feature can be included in the .net application?
Can some help me, what needs to be done for this?
First, look into a UPS (un-interuptable power supply)
Second, look into creating persistent transactions, transactions that will save early and often, but not commit until you tell it to. This goes a little beyond the typical transactions in TSQL.
PowerFailureException class will solve this. Actually just maintain power with a UPS. The only other option really is to maintain atomicity for database transactions.
If it's a hard power-cut (like the battery removed on a laptop while unplugged), then there's not much you can do other than write to disk every. step. of. the. way. (Talk about a performance hit.) And also make sure that you have something recorded to let the application know when it starts back up what it was in the middle of doing before, so it can either continue, or retry the operation.
If it's a power-cut, like the power button being pressed to shutdown/sleep/hibernate the computer, then listen for the SystemEvents.PowerModeChanged event and act accordingly.
Lastly, make sure that if your data would be corrupted if halfway written to a database, make sure your database writes are atomic (either all the changes happen and are accepted, or none of them are).
What you really want are atomic on disk transactions. There are many ways to perform these, but often times if you are using an existing database product it will be done for you.
If you rolled your own database or file formats, you have some work cut our for you depending on your file format.
You can append the current information being received to the file system. It will be a performance hit, but will allow you to get back to the last item being captured.
When the application starts detect if there is a pending file, and provide the option to recover. Load the data saved in the file appropriately.
Once you have all the information, when you are doing the process that happens when paying, make sure to record any significant changes in the process atomically. If you are hitting external systems, record when you are initiating the operation and when it comes back right away. In the above there is always a window of time when it can fail, but you want to keep it as short as possible and to have enough information for the recovery processes. Worst case if the system can't automatically recover, you want it to have enough information to determine where in the process it stopped.