Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

web service auto update proxy 2

Status
Not open for further replies.

gnobbster

Programmer
May 8, 2007
3
0
0
PH
what are the possible ways (and the most effective) to automatically update a proxy in a web service? for example, i have 2 client computers and a server. both the client computers connect to the server and the server passes the business object CEmployee to the clients. if i edit a property on the proxy on client1 (eg. CEmployee.FirstName), will computer2's proxy of that CEmployee have its FirstName be updated too? if not, how can i achieve this?
 
This is a theoretical possibility, having never actually attempted this myself...

Set up the server so that only one client at a time can open the data in question for editing. This will help prevent accidental overwriting and other problems. Also, the server should broadcast changes to the opposite client when detected.

Or, you could try the same approach the Tubes program uses. Its a file sharing program that actually stores all of the data in 2 or more places. The server maintains the master copies of its files while the clients store their own copies. If a client copy is changed, the change is uploaded to the server, the server replaces the master copy, then whenever a client connects, it synchronizes by having the client download the new master copy.

 
Thanks for the reply JBlair. I also found an article about this stuff. Its about concurrency control. I found a great article on MSDN (by rock Lhotka). It seems that the best choice is to implement optimistic concurrency w/c means that you let the user know if a change has been made by generating an exception. Again thanks for the reply. Ive been posting this question on many forums for days!
 
Depends on the expected usage. For a system with a high proportion of reads to writes (most cases), optimistic locking is best. For systems where there is likely to be a high degree of contention for 'hot' resources, then users may get frustrated if they are constantly being bounced out by optimistic lock failures. In which case, it may be better to actually take a pessimistic lock (better still, redesign your system to remove the hotspot).

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object::perlDesignPatterns)[/small]
 
Thanks for the article link MisterStick. Rocky Lhotka is indeed one of the most knowledgeable guys out there.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top