Sachil,
I have worked on an application that did exactly that. That was a financial
system too, so let me share what I learnt out of that first .. maybe you'll
find it helpful.
In my scenario atleast, I had so much data to worry about, so my first
reaction was that I will use a database. Beacuse a database inherently goes
to the file system, and it does involve a lot of transactional locks, a
database really didn't give me the right architecture. I instead then ended
up creating a huge in-memory cache of data in unmanaged C++. The data I was
managing was a huge 12 GB in-memory cache of symbols and their historical
prices. Various algorithms would run on that data, to analyze the historical
data - a database would just not have cut it.
Thought I'd share my experience on the implementation difficulties I faced
, but irrespective of if you choose a database or an in-memory cache, this
is more a remoting problem than an ADO.NET problem. Generally for eventing
there are two approaches.
a) Logical - The central server informs the clients of a change. Generally
not scaleable, but better response time. This can be implemented in Sql2k as
an extended stored proc that touches a file, a FileDependency object that
fires up some code to send off a notification. SQL2k5 has much better
alternatives.
b) Better approach - The remote clients keep checking for a change (I know
this sounds crazy in a millisecond environment but keep reading). Usually
the change check is implemented as "IsUpdateAvailable". If one is available,
a second method call is made to the central server farm, which returns the
actual data. This can live within the millisecond delay range, on a LAN
environment but what is notable about this approach is that the server is
stateless, so you can network load balance it as your needs grow. Might I
point that IM services, such as MSN messenger rely on this kind of
approach - and that is quite instantaneous huh?
Now, you can choose either a) or b), but if you are writing this application
for hundereds of users, you may want to go with approach b instead.
Specifically in approach a), the client is *listening* for a notification,
and in approach b) the server is listening. So this means once you have such
a notification setup, you can simply setup a CAO remoting service to fulfill
the necessary communication. In approach a) the service would have to exist
on both the client and the server, but in approach b) the service would
exist only on the server
.
Hope this helped. Sorry for the longdrawn answer, I'm a bit high on coffee
;-)
- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx