Board index » delphi » Multiple Clients / One Server

Multiple Clients / One Server

Question:

I have two or more clients looking at a data-aware grid that that is
filtered to view certain data only from the table for their current
operation.  Client A modifies one of the filtered records and Client B
is still just looking at their data-aware grid.  How can I update Client
B's grid with the new information that Client A has supplied for the
record in question, without doing a refresh on the table from Client B?
Is this possible?  Are CachedUpdates and ApplyCacheUpdates used for
this...?

I am trying to develop a client/server app that more than one client can
do the same operations on a group of records and I am trying to prevent
all the clients from stepping on each other when accessing the
records...

thanks in advance...Gerry

 

Re:Multiple Clients / One Server


Quote
Gerald Benusa wrote in message <37163C4A.ED967...@bankersbank.com>...

>I am trying to develop a client/server app that more than one client can
>do the same operations on a group of records and I am trying to prevent
>all the clients from stepping on each other when accessing the
>records...

There are two issues here - displaying the most up-to-date data, and
preventing contention - different users stepping on each other's updates.

Taking the contention problem first, different SQL servers handle the issue
different ways - so there is no single way to tell you how to handle this.
In general though, there are two basic philosophies for the client end:

1. Pessimistic: When a user reads a record for the purpose of update, check
to see if it's locked by someone else first and if so, refuse the request.
If not locked, lock it. This is the safest approach, but depending on the
SQL Server, locking a record can actually result in locking a page of
records or even the entire table - so other users are locked out of
*several* records even though only one of them is actually at issue.

2. Optimisitc: Assume there will be no contention, let any user read and
*attempt* to update any record any time, but the first one in wins - all
others get an error when they try to post their changes if those changes
collide. As long as contentions do not happen, this method is better for
user productivity - they are never locked out of any record. But when it
*does* happen, it could be frustrating for the "losing" users. Interbase is
based on optimistic locking.

In my current project I'm employing both methods - for all general (e.g.
maintenance) forms, optimisitc locking is fine. For the scheduling engine, a
scheduler must be able to tell a customer a certain time/resource is free
and then subsequently be able to reserve it without threat of it being taken
by someone else while waiting for the customer's confirmation - therefore
pessimistic locking must be employed.

For keeping the display up-to-date, there is no automatic way to do this in
SQL. Interbase has Event Alerters that can be triggered. This is a good
solution as long as you can dictate that Interbase be used. For everything
else though, the only "portable" way AFAIK is to refresh your displays on
some regular interval - it still won't be "real-time" - how often to refresh
is up to you, if there is a lot of data to refresh, this can present
performance issues.

--
Wayne Niddery - WinWright Consulting
Delphi, C++Builder, JBuilder, InterDev --
http://home.ican.net/~wniddery/RADBooks.html
...remove chaff when replying...
"You know you've landed gear-up when it takes full power to taxi"

Other Threads