4: Occasionally Connected Smart Clients in Visual C#

Drawer Code39 in Visual C# 4: Occasionally Connected Smart Clients

In reality, pessimistic locking is only suitable for a few types of occasionally connected applications. In document management systems, for example, users may intentionally check out documents for a prolonged period of time while they work on them. However, as scalability and complexity increase, pessimistic locking becomes a less practical choice.

Most occasionally connected smart client applications use optimistic locking, which allows multiple parties to access and operate on the same data concurrently, with the assumption that the changes made to the data between the various parties will not conflict. Optimistic locking allows high concurrency access to data, at the expense of reduced data integrity. If conflicts occur, you need a strategy for dealing with them. In most offline scenarios you need to use optimistic locking. Therefore, you must expect data conflicts to occur, and you must reconcile them when they do.

As your users work offline, any data they have changed is not confirmed as a change on the server. Only after the data has been merged with the server and there are no conflicts can the data truly be considered confirmed. It is important to keep track of unconfirmed data. When the data has been confirmed, it can be marked as such and used appropriately. You may want to display unconfirmed data in your application s user interface in a different color or font so that the user is aware of its tentative nature. Generally, your applications should not allow data to be used in more than one task until the data has been confirmed. This prevents unconfirmed data from spilling over into other activities that require confirmed data. Using confirmed data is not a guarantee that there will not be a conflict, but at least the application will be aware that at one time the data was confirmed and has been subsequently changed by someone.

Even if data has not changed, it can cease to be correct because it is no longer current. This data is known as stale data. As you design your smart-client applications, you need to determine how to deal with stale data and how to prevent your smart clients from using stale data. This is particularly important for occasionally connected smart clients because data may be current when a client first goes offline, but may become stale before a client goes online again. Additionally, data that is current on the client could be stale by the time it reaches the server. For example, a salesperson could create an order for various items on a Friday using valid data, but if he or she doesn t submit the order to the server until the following Monday, the cost of those items could have changed.

Note: If a service request is queued and is ready to be sent when your application goes back online, the chances that the request may encounter a data conflict or exception increase the longer that the request is queued. For example, if you queue a service request that contains an order for a number of items and you don t send the request for a long time, the items you order may be discontinued or sold out.

There are a number of techniques you can use to handle stale data. You can use metadata to describe the validity of data and show when the data will expire. This can prevent stale data being passed to the client. At the server, you may choose to check any data from the client to determine if it is stale before you allow it to merge with the data on the server. If the data is stale, you could make sure that the client updates its reference data before resubmitting the data to the server. The risk of stale data is greater with occasionally connected applications than with always connected applications. For this reason, your smart client applications will often perform additional validation steps to ensure that the data is valid. By adding extra validation into the system, you can also make sure your services are more tolerant of stale data, and in some cases you may be able to automatically handle the reconciliation on the server (that is, map the transaction to the new account). Sometimes, stale messages are unavoidable. How you deal with stale data should be predicated on the rules of the business you are modeling. In some instances, stale data is acceptable. For example, suppose that an order is submitted for a particular item in an online catalog. The item has a catalog number, which has become stale because the online catalog changed. However, the item is still available and has not changed, the catalog number change has no effect on the system, and the correct order is generated. On the other hand, if you are performing a monetary transaction between two accounts and one of the accounts has been closed, you cannot perform the transaction. Here the staleness of the data does matter. A good general rule is to have business objects handle stale data situations for you. Your business objects can validate that data is current, and if it is stale, either do nothing, reconcile the stale data with equivalent current data, pass the information back to the client to be updated, or use business rules to automate an appropriate response. Reconciliation of stale data may occur on the client, the server, or both. Handling reconciliation on the server allows your application to readily detect a conflict. Handling reconciliation on the client offloads some of the responsibility to the user or administrator who may be required to manually resolve any conflicts.