DevForce Community Forum : [ANSWERED] Multi-User Behavior

I think I understand the gist of either procedure. The trouble comes in with the vast amount of code to create for this. I realize that not everything needs this kind of data synchronization; however, it will get messy. Also, where do these things happen within DF/CAB? To keep things separated from the view, I suspect it would be best to implement the polling from the presenter. Or, is there an even better place to do this...controller? workitem? rootworkitem? Should I somehow consider a service mechanism to make this happen?

In addition, are SQL Server 2005 Notification Services the only thing that could drive the push mechanism? I do not have SS2K5, nor do I expect to upgrade to it (2008 is getting close). How am I limited without that database management system?

What is DevForce's Push Feature?

Some of our customers want the central server to "push" information to registered clients when a particular something happens.

Note that this communication occurs when the server thinks it should happen, not in response to any particular request from a client.

"Push" technology is what makes this work.

The Polling Alternative

We recommend async query to our customers who want to learn when something of interest has happened. For example, the client can issue an async query to learn if there have been any changes to the list of currently available theater seats. Every few seconds, the client asks the database "Any changes to the theater seats?". The database responds "No" most of the time but occasionally responds with a collection of theater seats that have been changed (e.g., reserved).

This is called "polling".

What's Wrong with Polling?

We think it is just fine in 99% of cases.

Recently, a number of prospects have been insistent that polling is bad - or at least bad for their applications.

The perceived problem with polling is that a great many clients could be checking in over and over, clogging the network and diminishing server performance. It's a bit like having a thousand kids in the back seat screaming "are we there yet?".

Servers, unlike human parents, do not get tired or irritated. They do have to respond to each request, as often as it arrives. The fear is that if a great many clients clamor for information and if there is limited bandwidth to carry the traffic in requests and responses, the network and / or server performance will deteriorate.

With "Push", clients register just once that they want to know when "this" (whatever "this" is) happens: "tell me when we get to grandma's house".

The BOS will be able to host a "daemon" process that (a) clients register to and (b) that calls back into the client when "this" happens: "hey, kids, we've arrived; say Hi to grandma". The client either finds all the information needed inside the call-back from the daemon or knows to go get what it wants: "Hi grandma; where are the presents?".

This feature makes sense only with the BOS

Although one could write a daemon that runs on the client in 2-tier, it won't be achieving its purpose of reducing the chatter of a "polling" strategy. That's because the daemon itself typically polls*. That's fine when the daemon runs on the host server; it translates to client-side polling when the daemon runs on the client.

* It is theoretically possible to install MSMQ (Microsoft's messaging technology which provides push technology) on each client and design the daemon to use it. The daemon would not have to poll. However, this approach is only viable if the client is already running MSMQ for some other reason - it's a pretty tricky install just for a DevForce client app.

This is why I described the BOS as providing "meaningful" push. You could do it 2-tier but you'd probably just be moving the polling out of your main thread and into another; you haven't really addressed the screaming child problem.

What if a Business Object Server is used?

(demo countdown: 40 minutes)

Building robust multi-user applications is non-trivial and requires careful application-specific design--there is no "out of the box" solution.

CAB (or rather the Cabana wizards) may have created the binding sources for you, but your code supplied their data sources (typically by querying data from a persistence manager). Keeping that data up to date is a raw DevForce task.

DevForce's managed lists synchronize EntityLists with changes in the cache of the related PersistenceManager in the executing client. As you've found, if coded properly with managed lists, drop-downs will stay in sync with their PM's cache.

The Cabana EntityManager class maintains local (client-side) synchronization between multiple PMs in the same executing client.

Synchronizing data in PMs of two client instances (that may be on opposite sides of the world) occurs by arranging to re-query the data. DevForce provides some tools, but it's up to you to decide how they should be used in your application.

(DevForce does offer "push" technology, but it's complex and they tell me it's really "pull" under the hood.)

Obviously, synchronization occurs when the client is stopped and restarted.

Other options include,

Add a refresh button of some kind to force re-query.

Have your application periodically requery critical data.

Arrange to refresh (requery) when a particular page is displayed or some other UI event occurs.

Also keep in mind that, beyond synchronization, multi-user applications must deal with concurrency conflicts--handling the case where two clients have changed the same entity and then each tries to save. Does the second save overwrite the first save's changes? Is an error thrown?

Again, DevForce provides some tools and guidance (there's a good tutorial on the subject), but you must provide application specific implementation.

So I guess a possible answer to your exec's question is "It will once we complete the design and implementation of the application".

By the way, most of the tutorials are obviously not designed with CAB in mind. As a matter of fact, in most cases, I cannot follow a tutorial and still consider my code CAB-worthy.

The answer is, "It depends".

If you code your application the same way as is done in many of the tutorials (e.g., "Adding and Deleting Business Objects" or "Working with ComboBoxes"), your new machine will not show up in your fellow technician's dropdown list. However, if your fellow technician adds a ListManager to the EntityList in his dropdown list to filter all existing machines, the machine you just added will show up automatically in his dropdown list.