UvMoney Concurrency

3 February, 2008. 773 words.

I’ve been thinking more about concurrency issues in UvMoney. The last time I posted about UvMoney, I was switching over to a database back-end mainly to handle concurrency. Then I decided that was pretty silly, considering that in my current “production” environment, there are only two people that can possibly use the data at the same time. Also, I didn’t want to tie myself to a database. So I went back to the easy-to-digest XML files.

Now I’m thinking about ways to handle concurrency again. Even though there are only two of us working on this file, I’m still paranoid about one of us stepping on the other’s data.

The issue is that all of the accounting data is stored in a single XML file, and there is an ASP.NET web interface that multiple people can use simultaneously. Various situations of concurrency need to be addressed.

For example, what happens if Person A adds a transaction, and Person B adds a transaction at the same time? Upon submiting the new transaction, Person A’s postback will load the XML file, add the new transaction to the collection in memory, and save the XML file back out with the new transaction. If Person B’s postback loads the XML file before Person A has finished saving his updated XML file, there could be problems:

Person A loads XML file into memory.
Person A adds new transaction A to the data.
Person B loads XML file into memory.
Person A saves new XML file with new transaction A.
Person B adds a new transaction B to his copy of the data.
Person B saves new XML file with new transaction B, overwriting and discarding transaction A!

We* need to implement some kind of locking scheme and alter the process:

Person A locks the XML file.
Person A loads XML file into memory.
Person A adds new transaction A to the data.
Person B attempts to load the XML file into memory but can’t because it’s locked by Person A - B must wait until A unlocks it.
Person A saves new XML file with new transaction A.
Person A unlocks the XML file.
Person B is now able to lock the XML file.
Person B loads the unlocked XML file which includes the new transaction A.
Person B adds the new transaction B to the data.
Person B saves new XML file with new transaction B and transaction A.
Person B unlocks the XML file.

The same locking scheme can be used when Person A and Person B edit existing transactions.

Person A locks the XML file.
Person A loads XML file into memory.
Person A edits transaction A.
Person B attempts to load the XML file into memory but can’t because it’s locked by Person A - B must wait until A unlocks it.
Person A saves new XML file with modified transaction A.
Person A unlocks the XML file.
Person B is now able to lock the XML file.
Person B loads the unlocked XML file which includes the updated transaction A.
Person B modifies transaction B.
Person B saves new XML file with modified transaction B and modified transaction A.
Person B unlocks the XML file.

When editing the same transaction, we need to add one additional safety check:

Person A locks the XML file.
Person A loads XML file into memory.
Person A alters the transaction X.
Person B attempts to load the XML file into memory but can’t because it’s locked by Person A - B must wait until A unlocks it.
Person A saves new XML file with updated transaction X.
Person A unlocks the XML file.
Person B is now able to lock the XML file.
Person B loads the unlocked XML file which includes the updated transaction X.
Person B compares the contents of the loaded transaction X to a previously cached copy of transaction X.
If the contents are different, report that Person B’s changes will ovewrite Person A’s changes and give the user a chance to examine the changes and abort.
If Person B wants to continue overwriting, Person B alters transaction X. Otherwise go to 13.
Person B saves new XML file with the updated (and overwritten) transaction X.
Person B unlocks the XML file.

That should handle concurrency issues well-enough for my purposes. Now all I need to do is add all of that.

One odd habit I picked up early in my programming career is writing comments and documentation in second person. Eg. “// We should optimize this part.” I think it’s because I saw a lot of Amiga sample code that did that.

Related