Jeff's Blog

Fudge is a confounding substance. It like many hybrid confections, borrows its properties from its constituents in a less than intuitive manner, amalgamating both the varied flavors and textures into an even more insidious concoction. I don't like confectioner's sugar, I can't say I'm a fan of cakes, and while I won't turn my nose up at chocolate, I don't fiend for it. Given that, one should be able to assume that I don't like fudge, and in fact, I don't. But not for any reason related to my dislikes of its majority parts.

Fudge has implicit nature. While many confections at least make some attempt to describe what flavor or form it is they are attempting to evoke, fudge skitters past the formalities and pummels your taste buds with a stingingly sweet darkness that is, at the minimal an unbidden invasion of flavor. I don't like fudge simply because it's name is not descriptive of the experience it will provide. I do not like fudge because, as its namesake "fudge factor" implies there is no precise incarnation upon which to base my interpretation. I do not fudge because it smacks all too much of a requirement to be seethingly sweet, chocolaty and yet eerily cake like. I do not like fudge because provides no explicit target unto which it can strive

One of the classic problems for any software application is concurrency. Even in the confines of the single data editor model, there are still issues to consider, and worse there is now the expectation that web based application will perform in an always synchronized manner like their desktop cousins.

With the switch to interactive web clients, a new set of problems has arisen around just who (client or server) owns the real data. In many classic we applications there was a clean split in that the server always owned the official copy of the data, but the client owned a transitory current copy, meaning that if the client submitted the data, then its copy was to be trusted fully, and would replace the server's copy.

While this model certainly has its detractors, such as potential data-loss if the client is closed without publishing its copy of the data to the server, or worse in multi-data owner systems data overwriting could be a big issue; the big upside was the predictability of the model for both the end-user and the developer.

But event in the earliest days of the XmlHttpRequest cracks began to appear in this model. Once a set of data could be subdivided and manages as singular data points, the first holes appeared. It was now possible for client server conflicts to occur. A simple case could be two dependent data values on the client. The user modifies the first, and upon completing the modification, the value is sent to the server. The user continues to modify the second value, however the server fails validation of the first value, at this point the client can react in many different ways, all of which could possible require some new training, or adjustments from the end-user.

Mix in the ability to disconnect the UI from the state of the data, and then you have a real recipe for disaster. Consider a simple slider like control on the client, something like this "ß 12à". The way this control works, every click is first rendered on the client, and then a data change notification is sent to the server, so if the à arrow is clicked the client value is incremented to 13, and a notification is sent to the server, where the current value is updated to 13.

Even in the tidy world of single data owners, it's very easy in the web-world to have the client enter a state where the value it believes to be current is not what the server believes the value to be. All of the client-side event throttling, and redundant asynchronous post-back checks can't prevent the possibility of the perfect user induced click-maelstrom that causes the server and client to differ by the that ever so critical single value.

The real killer for web apps though was the loss of the submit (save) button, even if the client fell out of step with the server, as long as there was a way to give a final, this is what I meant push of data to the server, it was just a rickety bridge, not a real problem. These days though its ever more increasingly the case, that end users will expect that just like desktop app, their copy of the data is always in sync with the server and therefore should require no final approval.

One way to think about this kind of problem is the old-fogies' balancing the checkbook problem. In a very similar fashion, there are two owners of the current data in a world of banks, checks, and balance books.

On the one hand, the bank is the actual owner of the "how much money is there" data point. No matter what the checkbook says, the bank is the definitive authority.

On the other hand a well maintained balance book has a much more accurate representation of the "how much money is there" data point, and it fact the account holder must rely on the value in their balance book to determine if they can write more checks.

This is because the account holder (in the form of their balance book) has information that the bank does not yet, about how the data will be changing. They know about the checks in the mail for the water, electric and gas bills, and therefore by recording them in their balance book, they have the best and most trustable representation of the account's available balance.

So what does that mean for the bank, obviously it can't just accept the information in the clients balance book as correct. It's entirely possible the account holder made a math error, or forgot to record something, so really who does have the real value. If it's the bank, how would the account holder know not to write checks against money that backs checks already written?

In the next blog post I plan to pull out things that I think work from the bank/balance book model as a concurrency management pattern, and also highlight some aspects that are not applicable to software based systems.

Hopefully If I can follow my own directions I will be able to produce a useful pattern for addressing this type of web base concurrency problem.