jakarta-jcs-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Parvathi Rajaraman <Parvathi.Rajara...@metcash.com>
Subject RE: Regd Serializing Cache
Date Mon, 10 May 2004 04:09:25 GMT
Actually, I wanted to make the design flexible enough, so that due to some
reasons, if we want to switch over to any other cache implementation, it
will be totally transperant to the application. So I reckon, the best idea
is to leave the serialization aspect for now as it might lead to other
problems. Is that right? So whenever there is an application re-start or
something, its better we flush the cache and re-build it from scratch??

Thanks
Parvathi

-----Original Message-----
From: Aaron Smuts [mailto:aasmuts@wisc.edu]
Sent: Monday, 10 May 2004 1:08 PM
To: 'Turbine JCS Users List'
Subject: RE: Regd Serializing Cache


I guess what you are trying to do is to create something like the
commons logger in front of the cache.  This is a good idea if you want
to switch caches, but it can have a slight effect on performance.  

Ideally, you would just get the cache region in a class like you would a
logger and store it as an instance variable.  This does tie your code to
JCS though if you don't have a wrapper.   

Aaron



> -----Original Message-----
> From: Aaron Smuts [mailto:aasmuts@wisc.edu]
> Sent: Sunday, May 09, 2004 9:57 PM
> To: 'Turbine JCS Users List'
> Subject: RE: Regd Serializing Cache
> 
> That might be nice, but the cache isn't a database.  You should never
> cache anything you can't recreate.
> 
> If you have several locals connected through the remote or lateral
> caches, then they can pull data from the remote store on request.
This
> lessens the possibility for stale data.  It is almost always better to
> restart a application without cached data.
> 
> Cheers,
> 
> Aaron
> 
> > -----Original Message-----
> > From: Parvathi Rajaraman [mailto:Parvathi.Rajaraman@metcash.com]
> > Sent: Sunday, May 09, 2004 9:33 PM
> > To: 'Turbine JCS Users List'
> > Subject: RE: Regd Serializing Cache
> >
> > Hi Aaron,
> >
> > In our initial design we had some thoughts like if there is a patch
or
> > something that is applied, we could just unload the contents of
cache
> and
> > re-load it as soon as the patch is deployed. That is we will not
loose
> the
> > cached data under any normal circumstances. This was just a thought
> and
> > later when we started using JCS for our caching, I could get hold of
> all
> > the
> > keys in the domain so that I could serialize them. Then I thought
that
> JCS
> > would do that automatically. I just had a read through disk caching
as
> > well,
> > but dont know whether is that the right thing to use.
> >
> > Thanks
> > Parvathi
> >
> > -----Original Message-----
> > From: Aaron Smuts [mailto:aasmuts@wisc.edu]
> > Sent: Monday, 10 May 2004 12:30 PM
> > To: 'Turbine JCS Users List'
> > Subject: RE: Regd Serializing Cache
> >
> >
> > Why do you need this? Please explain.
> >
> > The disk cache does something like this when you call dispose.  When
> you
> > start it back up it will load the saved contents.  This
functionality
> > can be shut off, since it can lead to huge problems with stale data.
> >
> > Aaron
> >
> > > -----Original Message-----
> > > From: Parvathi Rajaraman [mailto:Parvathi.Rajaraman@metcash.com]
> > > Sent: Sunday, May 09, 2004 6:38 PM
> > > To: JCS MAILING LIST (E-mail)
> > > Subject: Regd Serializing Cache
> > >
> > > Hi,
> > > I have just written a simple implementation of caching using JCS.
I
> > > thought
> > > I will be able to write a unloadCache and loadCache method which
> will
> > > basically serialize and deserialize the contents of the cache. Can
> > anyone
> > > help me with regds to how to do this??
> > >
> > >
> > > Many Thanks
> > > Parvathi
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > turbine-jcs-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > turbine-jcs-user-help@jakarta.apache.org
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> turbine-jcs-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> turbine-jcs-user-help@jakarta.apache.org
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> turbine-jcs-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> turbine-jcs-user-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
turbine-jcs-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
turbine-jcs-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-jcs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-jcs-user-help@jakarta.apache.org


Mime
View raw message