How to refresh server caching dynamically when we have the web application running in clustering environment ?

[Marimuthu Udayakumar]

As Received From Vinod Sir,

Problem Statement: How to refresh server caching dynamically when we
have the web application running in clustering environment

Description: Consider a typical webapplication which runs on an
application or web server in clustering mode. Let us say we have 3
nodes in the cluster and the application is running on these 3 nodes
and serving all the user requests. There are some property values that
are stored in database and instead of going to database every single
time this application maintains a cache at server side, at node level,
and stores these property values in the cache and serves the values
from the cache.

Now we update on of the property value in the database. How do we
ensure that this updated value gets reflected in cache across all the
nodes?

There are lot of ways to solve this. Would like you think and come out
with an approach. Share the approach with the team.

[Marimuthu Udayakumar]

Hi All,

Consider this approach, server (holding the DB) notifies nodes which
will initiate the synchronization process.
This implies that the update has to be done from within a component in
the web application, once the update completes it can signal another
component in the web application to reload the new properties.


Yours,

Marimuthu Udayakumar.




On May 3, 1:23 pm, Marimuthu Udayakumar <teknoturf...@gmail.com>
wrote:

[Marimuthu Udayakumar]

Hi All,

We can also approach this by distributed caching with inherent
synchronization mechanism. In Microsoft world, we have Velocity
[http://msdn.microsoft.com/en-us/magazine/dd861287.aspx]
and
[http://msdn.microsoft.com/en-us/library/dd129907.aspx#References]


Yours,
Marimuthu Udayakumar.


On May 3, 1:29 pm, Marimuthu Udayakumar <teknoturf...@gmail.com>

> > with an approach. Share the approach with the team.- Hide quoted text -
>
> - Show quoted text -

[Vinod Kumar Burugupalli]

Marimuthu,

Distributed caching is one way where we maintain the cache at central
location and when ever a cache entry is updated we update this central
location.

1. What about scenarios where we dont have any distributed caching
available and we need to cache at each node?
2. In what scenarios we go for distributed caching?

Regards,
Vinod

> --
> You received this message because you are subscribed to the Google Groups "TECHNICAL KNOWLEDGE SHARING  FORUM - TEKNOTURF" group.
> To post to this group, send email to technical-knowledge-sh...@googlegroups.com.
> To unsubscribe from this group, send email to technical-knowledge-sharing-...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/technical-knowledge-sharing-forum---teknoturf?hl=en.
>
>

[Marimuthu Udayakumar]

Hi Sir,

I am surfing your first point [ 1. What about scenarios where we dont
have any distributed caching
available and we need to cache at each node? ].I will post answer
once get proper.

And For Second, [ 2. In what scenarios we go for distributed
caching? ]

Distributed caching is used when a cache is represented on
more than one participant (node) at once.

There are many topologies involved in distributed mechanisms (not just
cache!) - the two basic starting points are hub-and-spoke and mesh
topologies. Most other topologies can be considered as variants or
mixtures of these two, although there are of course exceptions.

1. Hub and Spoke

The hub and spoke topology has the concept of a central server, and
many clients (participants, using our definitions) connect to the
central server. The main server is the cache's "system of record"
although it may not be the application's system of record (and often
isn't). The network bandwidth available to the central server is a
limiting factor here.

One strength of this topology is that network management is usually
very simple, and that only one system has to be optimized for data
access: the central server.

Usually, systems with the hub and spoke topology have a backup live on
the network in the case of failure; therefore, client systems are each
connected to two servers (one primary, one backup).

2. Mesh

Mesh topologies are topologies in which each participating node is
connected to every other participating node. There's usually not a
central server in this topology, although there might be a
coordinating process of some kind.

Each participant is a peer to the other, so there's no dominant
server, nor is there an authoritative place for data to live. Network
limitations are per-participant.

This is a very, very common topology for clustered environments.
Participants tend to prefer data cached locally, which speeds things
up; synchronization, however, can be costly depending on the
transaction strategy.

Yours,
Marimuthu.


On May 3, 4:48 pm, Vinod Kumar Burugupalli <bvinodku...@gmail.com>
wrote:

> > For more options, visit this group athttp://groups.google.com/group/technical-knowledge-sharing-forum---te....- Hide quoted text -

[Marimuthu Udayakumar]

Hi Sir,

For non distributed caching scenario,
------------------------------------

what about having a process that reloads these values every few
minutes? If this is a java based app, we could use timer task or
Quartz (for more advanced scheduling).

Each node would have to refresh its cache independently, but using
Quartz we can ensure that the refresh happens at about the same time
on each server

I am exploring for best approch to this scenario, Once catch it, I
will post Sir,


Yours,

Marimuthu.


On May 4, 3:15 pm, Marimuthu Udayakumar <teknoturf...@gmail.com>

> > > For more options, visit this group athttp://groups.google.com/group/technical-knowledge-sharing-forum---te...Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -

[Vinod Kumar Burugupalli]

Thank of the resources (server, io and memory) it is going to consume
to maintain the scheduler and poll for changes every 2 minutes. Can we
do something on demand?

Regards,
Vinod

> For more options, visit this group at http://groups.google.com/group/technical-knowledge-sharing-forum---teknoturf?hl=en.
>
>

[Marimuthu Udayakumar]

Hi sir,

One more approach ,

There are many caching libraries (even open source) available which
also support clustered applications. One such library is OsCache, it
supports clustering by communicating through JMS or JavaGroups.

If we prefer, we can easily build such a solution using JMS or similar
mechanisms. The key here is to send each individual nodes message to
clear their respective caches. So each node can work and cache
independently but when one node updates/flushes its cache, it notifies
others.

http://www.opensymphony.com/oscache/wiki/Clustering.html



Yours,
Marimuthu.


On May 6, 5:36 pm, Vinod Kumar Burugupalli <bvinodku...@gmail.com>
wrote:

> >> > > For more options, visit this group athttp://groups.google.com/group/technical-knowledge-sharing-forum---te...quoted text -

>
> >> > - Show quoted text -- Hide quoted text -
>
> >> - Show quoted text -
>
> > --
> > You received this message because you are subscribed to the Google Groups "TECHNICAL KNOWLEDGE SHARING  FORUM - TEKNOTURF" group.
> > To post to this group, send email to technical-knowledge-sh...@googlegroups.com.
> > To unsubscribe from this group, send email to technical-knowledge-sharing-...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/technical-knowledge-sharing-forum---te....- Hide quoted text -

[Vinod Kumar Burugupalli]

Marimuthu,

JMS approach looks interesting. Can you try this out and let me know
if this works? If yes, post a design.

Regards,
Vinod

> For more options, visit this group at http://groups.google.com/group/technical-knowledge-sharing-forum---teknoturf?hl=en.
>
>