Prev: Run SQL Script from Console application
Next: WPF Context menus and "scope"
From: Eric on 17 Nov 2009 17:21
When a system is distributed over multiple servers, what are the
recommended methods for accessing data (like user records) that must
be maintained globally in one spot? IOW, http exchanges with a large
vendor could connect to a servers in one of several different
locations, but common data (user's credit card info, address, etc)
would need to be constant through the exchange.

This scenario would seem to counter some of the advantage in using a
distributed system to begin with, so I presume that some clever
methods have been devised to deal with this.

Any notable books or other references that cover the mechanisms?

[PS: Is the "patterns" group dead?]
From: Arne Vajhøj on 17 Nov 2009 22:35
Eric wrote:
> When a system is distributed over multiple servers, what are the
> recommended methods for accessing data (like user records) that must
> be maintained globally in one spot? IOW, http exchanges with a large
> vendor could connect to a servers in one of several different
> locations, but common data (user's credit card info, address, etc)
> would need to be constant through the exchange.
>
> This scenario would seem to counter some of the advantage in using a
> distributed system to begin with, so I presume that some clever
> methods have been devised to deal with this.
>
> Any notable books or other references that cover the mechanisms?

The two standard techniques are:
- store data in shared database
- store data in memory and replicate between between servers

The first is the most commonly used in .NET.

Arne
From: Wazza on 17 Nov 2009 23:16
1) if you are using oracle or some such "big" database solution use
the replication stuff therein (dont reinvent the wheel here)
2) If you are rolled your own database solution consider using a of
the self "big" database solution instead.
3) If you must share date like this between servers consider the
importance of availabity of the data and the speed of execution vs the
importance of not replicationg data.

Consider the many situations where data replication falls down (such
as a server dies and all transactions on that server made before the
last sync are lost).

Consider situations where confilctiong things happen on different
servers at the same time. Ie if I a company has a corporate credit
card with 1000 dollars limit and the bank has 5 servers for
transactions and the 50 eployees are all over the world using using
the card all the time. It is very easy for a situation to occur where
not one server thought the limit was exceeded until the syn occurs.

If the issues of data replication are too much use a single server and
live with it falling over in heavy traffic. Otherwise grab an of the
self data solution that supports replicatiobn and be aware that even
then some things get through (um well that was the case 5yrs ago last
time I toughed anything like this). You will still need to write some
sanity code that looks for situations where business rules are
violated and sends an email to a human in your company alerting them
to manualy sort something out.

Also this may be an area which you don't want to screw up, If it was
me I would call in a good consultant at various stages to audit the
design and developed product.

-Wazza
 | 
Pages: 1
Prev: Run SQL Script from Console application
Next: WPF Context menus and "scope"