The question:

--can I design a solution to have each server maintain its own cache,
so that Whenever there is a "add" request from the client, the server
stores the data in its cache as well as into the database. And
whenever there is a "get" request from the client, the server will
first look into its cache, and if there is a hit, it will directly
return the data found in its cache to the client, but not forward the
"get" request to the database.

The issue is how to design a synchromization mechanism between those
servers, so that the servers' caches are kept in synch.

I think that this might be a traditional parallel programming issue,
but I am not aware of the solution. Any one please know of a solution?
BTW, I'd like not to have one centralized "cache server" to cache the
data.

The assumptions:

--The client's add/get messages are randomly dispatched to server 1,
2, or 3. These servers run in parallel.
--Each server forwards its received add/get message to the Database,
and forwards the database response (success/failure) back to client.
--Add and get operations on the Database side are atomic to each
other.
--The serves can communicate to each other.

The question:

--can I design a solution to have each server maintain its own cache,
so that Whenever there is a "add" request from the client, the server
stores the data in its cache as well as into the database. And
whenever there is a "get" request from the client, the server will
first look into its cache, and if there is a hit, it will directly
return the data found in its cache to the client, but not forward the
"get" request to the database.

On Oct 19, 7:34 pm, lmike <lmike3... at (no spam) gmail.com> wrote:

The question:
--can I design a solution to have each server maintain its own cache,
so that Whenever there is a "add" request from the client, the server
stores the data in its cache as well as into the database. And
whenever there is a "get" request from the client, the server will
first look into its cache, and if there is a hit, it will directly
return the data found in its cache to the client, but not forward the
"get" request to the database.

Yes, you can. But how will it will work depends upon your design
requirements.

The issue is how to design a synchromization mechanism between those
servers, so that the servers' caches are kept in synch.

I think that this might be a traditional parallel programming issue,
but I am not aware of the solution. Any one please know of a solution?
BTW, I'd like not to have one centralized "cache server" to cache the
data.

How often is data modified? How well is stale data tolerated? About
how many servers do you plan to have?

Do you expect the same server to use the same object over and over?

If data is rarely modified, then each server can cache as much data as
it wants. When a server modifies data, have it broadcast an
"invalidate" to all other servers.

If data that's, say, up to a minute old is well-tolerated, then you
can cache data for only a minute.

If there aren't that many servers and the database is really
expensive, it may be better to broadcast a request to all servers and
let any server that has current data serve it out of its cache.

There are more algorithms for this than you can shake a stick at, and
the correct one depends on how much locality of reference you expect,
how many servers you have, your operation mix (particularly read/write
ratios), and how 'fresh' data needs to be.

DS

On 2009-10-20, lmike <lmike3... at (no spam) gmail.com> wrote:

illegible ascii art deleted.



The assumptions:

--The client's add/get messages are randomly dispatched to server 1,
2, or 3. These servers run in parallel.
--Each server forwards its received add/get message to the Database,
and forwards the database response (success/failure) back to client.
--Add and get operations on the Database side are atomic to each
other.
--The serves can communicate to each other.
The question:

--can I design a solution to have each server maintain its own cache,
so that Whenever there is a "add" request from the client, the server
stores the data in its cache as well as into the database. And
whenever there is a "get" request from the client, the server will
first look into its cache, and if there is a hit, it will directly
return the data found in its cache to the client, but not forward the
"get" request to the database.

if an add request cannot invalidate cached get responses that could
work quite easily.

if it can you'll need to also forward the add to the other servers so
they can react apropriately (eg. drop the cache records that have been
invalidated)

The problem may be with the modify: when server 1 receives a "modify",
it can broadcast invalidate message to other servers. The issue here
is, a "get" right after the "modify" from the client may compete with
that "invalidate" message from server 1. If the "get" message hits
server 2 before the "invalidate" message coming from server 1, server
2 may find the (old) data in its cache and will return the (old) data
to client. The result in client's view is then wrong, i.e. he/she did
a "get" right after "modify", but got old data instead of the new
modified data.

On Oct 19, 11:05 pm, David Schwartz <dav... at (no spam) webmaster.com> wrote:
On Oct 19, 7:34 pm, lmike <lmike3... at (no spam) gmail.com> wrote:

The question:
--can I design a solution to have each server maintain its own cache,
so that Whenever there is a "add" request from the client, the server
stores the data in its cache as well as into the database. And
whenever there is a "get" request from the client, the server will
first look into its cache, and if there is a hit, it will directly
return the data found in its cache to the client, but not forward the
"get" request to the database.
Yes, you can. But how will it will work depends upon your design
requirements.

The issue is how to design a synchromization mechanism between those
servers, so that the servers' caches are kept in synch.
I think that this might be a traditional parallel programming issue,
but I am not aware of the solution. Any one please know of a solution?
BTW, I'd like not to have one centralized "cache server" to cache the
data.
How often is data modified? How well is stale data tolerated? About
how many servers do you plan to have?


First of all, I am sorry that when I said "add" in my previous
message, I really meant "add" or "modify', so, there can be actually
three actions from the client, i.e.
add, modify, and get.

-the data is modified less frequently, and the amount of data is not
big. So, don't need to care about traffic and storage space, etc.

-the client is supposed to immediately see the modified data, if he/
she does a "get" right after a "modify"

-there will be less then 10 (say, 3) servers, each of them runs on a
separate box.


Do you expect the same server to use the same object over and over?


I am not quite sure what you meant by "object" here, but the add/
modify/get messages go randomly to those servers. All the servers
always connect to the same client and the same database.

If data is rarely modified, then each server can cache as much data as
it wants. When a server modifies data, have it broadcast an
"invalidate" to all other servers.

If data that's, say, up to a minute old is well-tolerated, then you
can cache data for only a minute.

If there aren't that many servers and the database is really
expensive, it may be better to broadcast a request to all servers and
let any server that has current data serve it out of its cache.

There are more algorithms for this than you can shake a stick at, and
the correct one depends on how much locality of reference you expect,
how many servers you have, your operation mix (particularly read/write
ratios), and how 'fresh' data needs to be.

DS

I am thinking that for the add operation, it probably works ok: once
the server gets the response from the database saying that the add is
a success, it will broadcast the data to other servers, for them to
add to their cache.

The problem may be with the modify: when server 1 receives a "modify",
it can broadcast invalidate message to other servers. The issue here
is, a "get" right after the "modify" from the client may compete with
that "invalidate" message from server 1. If the "get" message hits
server 2 before the "invalidate" message coming from server 1, server
2 may find the (old) data in its cache and will return the (old) data
to client. The result in client's view is then wrong, i.e. he/she did
a "get" right after "modify", but got old data instead of the new
modified data.

I think that such a race condition will always exist. I now doubt
there is a solution to this problem, given all the requirements as
said above. Am I correct?