jakarta-jcs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hariprasath Manivannan <hari.manivan...@gmail.com>
Subject Re: Fwd: Query regarding remote cache
Date Thu, 12 May 2005 03:20:34 GMT
Hi Aaron, Hanson,
 Thanks for the clarification. I guess earlier I did not get the region 
concept of JCS correct. Now it is clear. 
 In my case, the source application B has to maintain a region for each of 
the client application that connect to B. A cache will be maintained at each 
of client application side(to reduce RMI network calls). This cache will be 
synchronized with the cache.
 I am really looking forward for the JMS option soon. In mean time, can some 
let me know the exact difference between the usage of remote cache vs 
lateral cache.
 Regards,
Hari

 On 5/12/05, Aaron Smuts <asmuts@yahoo.com> wrote: 
> 
> I'm not exactly sure what the question is either, but
> maybe this will help.
> 
> There is no synchronization on startup in JCS. It
> doesn't exist. I'm trying to figure out a way to do
> it . . .
> 
> JCS lets you can into regions, or what we sometimes
> call a cache. Think of a region as a hashtable that
> you get out of JCS by name.
> 
> For each region you can configure plugins, or
> auxiliaries, sort of like log4j appenders.
> 
> This is done on a region by region basis. If machines
> A and B have a region called foo and they are both
> configured to have a distibution plugin, then they
> will talk. If machine B also has a region named bar,
> but it is not configured for distribution, then
> elements put in bar will not be distributed.
> 
> You could configure machine B to distribute bar to C
> but not with A.
> 
> You can use jgroups, sockets, or the rmi centralized
> server for distribution. We will have a JMS option
> soon.
> 
> (Outside of the http lateral plugins, currently there
> is no really good way to just listen without also
> sending. There is also no good way to send without
> listening. That's why the JMS plugin would be useful.
> 
> We do have an http sender and a servlet listener that
> will do the trick. When we had embedded jetty this
> worked well. The JCSAdmin.jsp can also be used for
> deletions, but there is no prebuilt jcs way to call
> it.)
> 
> What we call the "remote cache" is the rmi server. It
> is robust, and has some failover capabilities.
> 
> Aaron
> 
> 
> --- Hanson Char <hanson.char@gmail.com> wrote:
> 
> > ---------- Forwarded message ----------
> > From: Hanson Char <hanson.char@gmail.com>
> > Date: May 11, 2005 9:28 PM
> > Subject: Re: Query regarding remote cache
> > To: Hariprasath Manivannan
> > <hari.manivannan@gmail.com>
> >
> >
> > The given URL is referring to the use of "remote
> > cache" in JCS, which
> > is not applicable to the use of lateral cache.
> >
> > Lateral cache is rather a "distributed index", which
> > AFAIK tries to
> > partition the entire cache into different nodes, but
> > with no guarantee
> > that the replicates of the same cache item is
> > consistent among all
> > nodes.
> >
> > So is the original concern related to Remote or
> > Lateral ?
> >
> > Hanson
> >
> > On 5/11/05, Hariprasath Manivannan
> > <hari.manivannan@gmail.com> wrote:
> > > Hi Hanson,
> > >
> > > I am looking into the following configuration for
> > my needs:
> > >
> > > http://jakarta.apache.org/jcs/RemoteAuxCache.html
> > >
> > > Also my understanding about Remote Cache vs
> > Lateral cache is:
> > > The remote cache can get updates from the local
> > cache only.
> > > Lateral cache is also a kind of remote cache, but
> > it can send update to the
> > > local cache.
> > >
> > >
> > >
> > > Regards,
> > > Hari
> > >
> > >
> > > On 5/11/05, Hanson Char <hanson.char@gmail.com>
> > wrote:
> > > > Hari,
> > > >
> > > > I am starting to think we are talking about
> > different things here. We
> > > > should clarify the terminology.
> > > >
> > > > 1) Are you referring to the use of a) remote
> > cache server or b)
> > > > lateral cache in JCS ?
> > > > 2) What does it mean by "Remote Cache
> > Synchronization" ? Is it an
> > > > extra step involved in the use of lateral cache
> > ? For AFAIK, there is
> > > > no such thing in using the remote cache server.
> > > >
> > > > H
> > > >
> > > > On 5/11/05, Hariprasath Manivannan
> > <hari.manivannan@gmail.com> wrote:
> > > > > Hi Hanson,
> > > > >
> > > > > I have attached a word doc depicting the
> > problem.
> > > > >
> > > > >
> > > > >
> > > > > Regards,
> > > > > Hari
> > > > >
> > > > >
> > > > > On 5/11/05, Hanson Char <hanson.char@gmail.com
> > > wrote:
> > > > > > What do you mean by "synchronization" ? Do
> > you mean when B tries to
> > > > > > update it's local cache, or C tries to
> > update it's local cache, or
> > > > > > both ? In all cases, A at most will only be
> > affected by a bunch of
> > > > > > cache item delete requests.
> > > > > >
> > > > > > Hanson
> > > > > >
> > > > > > On 5/11/05, Hariprasath Manivannan
> > <hari.manivannan@gmail.com > wrote:
> > > > > > > Hi Hanson,
> > > > > > >
> > > > > > > Thanks for reply.
> > > > > > >
> > > > > > > To clarify things about my query : The
> > client A is again another
> > > J2EE
> > > > > > > application. I referred to client because
> > it uses the data from my
> > > > > datastore
> > > > > > > application B.
> > > > > > >
> > > > > > > The scenario that I am worried is: If a
> > new client application C
> > > wants
> > > > > to
> > > > > > > use data from my store(using cache), then
> > a cache will be setup at
> > > > > client C
> > > > > > > and at the contents will also be stored in
> > the cache at "B"(My data
> > > > > store
> > > > > > > application). When synchronization
> > happens, the cache at A will
> > > updated
> > > > > to
> > > > > > > have the stuff that "C" requested.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Hari
> > > > > > >
> > > > > > >
> > > > > > > On 5/11/05, Hanson Char <
> > hanson.char@gmail.com> wrote:
> > > > > > > > When you say "client" side A and
> > "server" side B, do you mean A is
> > > a
> > > > > > > > client of server B, both using JCS (in
> > remote cache mode) ?
> > > > > > > >
> > > > > > > > If so, when B synchronizes with the
> > remote cache, the
> > > corresponding
> > > > > > > > cache items are flushed from A, so the
> > client will never hold data
> > > not
> > > > > > > > relevant to it.
> > > > > > > >
> > > > > > > > Hanson Char
> > > > > > > >
> > > > > > > > On 5/11/05, Hariprasath Manivannan <
> > hari.manivannan@gmail.com>
> > > wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I am planning to use the remote cache
> > feature of JCS in my J2EE
> > > > > based
> > > > > > > > > application. Basically my core
> > application is a static
> > > data-store.
> > > > > Since
> > > > > > > the
> > > > > > > > > data is static, I decided to use the
> > remote cache feature as
> > > this
> > > > > can
> > > > > > > reduce
> > > > > > > > > the RMI calls and network traffic.
> > > > > > > > >
> > > > > > > > > Now if I have a cache and both server
> > side and client side, then
> > > I
> > > > > may
> > > > > > > face
> > > > > > > > > issue during the remote caches
> > synchronization. The server side
> > > > > cache
> > > > > > > will
> > > > > > > > > be a global cache containing all the
> > cached objects. This is
> > > fine.
> > > > > But
> > > > > > > once
> > > > > > > > > synchronization is complete, the
> > client cache's will become
> > > similar
> > > > > in
> > > > > > > > > content to the server side cache. So
> > for any given client
> > > > > application
> > > > > > > cache
> > > > > > > > > will be holding data which is not
> > relevant to that application.
> > > > > > > > >
> > > > > > > > > Is there any way where by I still
> > maintain the remote cache, but
> > > > > > > synchronize
> > > > > > > > > with primary cache server
> > "selectively" - based on a application
> > > ID
> > > > > or
> > > > > > > > > something like that.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Hari
> > > > > > > > >
> >
> === message truncated ===
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
> 
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message