Lieven Cardoen

Concurrency is a big issue if you have business applications created in Flex. If two clients are editing the same data then the last client that saves the data will win.

Optimistic Offline Lock has the best liveness but you will only find out that a business transaction fails when you commit (save). So if you have been working for half an hour on some data the system will not commit the transaction and users won’t like this. Possibilites here are:

• Letting the user save his data under another name
• Letting the user decide whether his data should overwrite the existing data
• Letting the user compare the two versions and resolve the problems

Optimistic Offline Lock is easy to program. If you commit data, you need to check if the data in the database has changed since you loaded the data. Providing a solution however is more difficult.

That’s why we choose for a combination of Pessimistic Offline Lock and Implicit Lock. It’s harder to program but you don’t need any of the solutions above and it’s much more userfriendly. We combined it however with Coarse-Grained Lock, managing the concurrency of a group of objects together.

If a user opens an object to edit its data, then a message is send to all other clients saying that object of type A with id x is locked. A visual notification is shown in the other clients. When the user navigates away from editing the object, a message is send saying that the object of type A with id x is unlocked. We also send the id of the user and client locking the object. A drawback is that when a client opens an object for editing and leaves his desk for instance, then the object stays locked. However, after a half hour of inactivity, the user is logged out automatically.

The server side also holds a model of objects that are locked. If a client connects, it gets all the currently locked objects from the server. If a client disconnects, then the server cleans up the locked objects from that client and notifies the other clients. When two clients request a lock for the same object, then the client that triggers first the server side function to lock an object wins.

Concurrency was one of the biggest challenges so far and I’m not quite sure if our method is the most appropriate. It’s hard to test, hard to debug and your application starts to rely for a part on being able to send and receive messages (that’s why we made it configurable). We have implemented it using WebORB and it seems pretty stable.

Cheers, Lieven Cardoen