Hi all,
I'm kindly new with the CSLA framework and I have a multi-user question.
Imagine we have a table customer containing 10 records (customerA, customerB, etc).
We have 2 client machines.
We don't use any modal forms or whatever, so no reloading by opening a form is possible.
Look at the following situation:
- Client 1 gets the list of customers
- Client 2 gets the list of customers
- Client 1 changes the name of customerA in "CustomerA2"
- Client 2 changes the name of customerB in "CustomerB2"
At this moment the list of client2 is not refreshed, client2 doesn't see the changes of client1.
Can this issue be solved?
Or am I doing something wrong?
Kind regards,
Pascal Hendriks
Hi Pascal,
Search the forum for "lock" or "concurrency" to find some good discussion. There was also a lot of discussion in the old forum.
We use a manual locking mechanism where each record has an "IsLocked" and a "LockedByID" field. The users know they cannot change records when they don't have the lock (indicated in the status bar on the form). We've also added refresh functionality to anything with potential to change. In some cases, a quick check for new on the database is needed. It's a rather home-grown methodology, so it's very flexible.
_E
Use an observer pattern.
The observer pattern works well with Windows apps. Fortunately, web apps make it even simpler if you don't cache the dataset and refresh with each post-back from the database.
Simplest way to implement the observer pattern is to obtain the original collection of objects from factory object. For instance:
Client1.CustomerList = Server.GetCustomerList();
Client2.CustomerList = Server.GetCustomerList();
Now, when changes are made to either list, the collection is able to notify all clients that the list has changed.
Of course, this is overly simplified (and not a true implementation of the observer pattern) but it is part of the CSLA framework (via the ListChanged event in collections) and works fairly well with the built-in data-binding processes for WinForms.
The challenge in implementing the observer pattern, and where the above example fails, is when you are dealing with distributed systems and disconnected datasets (as with Web apps). Here, you need some way to communicate the change made on one system to the dataset residing on another. This is much more complicated and I defer to others who have implemented the observer pattern in a distributed environment to chime in with their input on how this could be done.
You may also want to consider some kind of Refresh() method on your collection to manually trigger re-fetching the data from the database as an option. We have utilized this approach before and had some UI's wired up with a timer to automatically refresh periodically - for pseudo-realtime monitoring functions.
Another approach that might suit your needs would be to refresh the collection automatically whenever changes are applied. This would consume a great deal of additional bandwidth, but if you are doing a refresh anyway, there's no loss in doing it when you apply the changes. So, in the example you gave, when the changes made by Client2 are applied to the database, the collection of customers on Client2 would be reloaded from the database thereby retreiving the changes made by Client1. Of course, now Client1 doesn't know anything about the changes made by Client2 until the next time it applies a change. This can cause problems unless you implement some sort of concurrency management such as a LastModified timestamp column to ensure data integrity on the update.
Hope that helps.
Copyright (c) Marimer LLC