You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-users@jakarta.apache.org by Phineas Fung <ph...@hotmail.com> on 2005/07/19 18:14:53 UTC

cache content survives a server restart

We're using JCS in a servlet environment, and want to see if we can have the 
cache content survive a server restart.

Becoz the cache management module is very far away from the servlet class, 
it's not very possible to pass a "shutdown" event to the cache management 
module (so that it can invoke JCS.dispose()).  But on the other hand, we 
want to have the cache content persists in a local file, and hope that its 
content is always up-to-date, so that we can rebuild the cache from the file 
when server restarts (e.g. after a crash).

Any insight will be greatly appreciated.

Thanks alot.


Best Regards,
Phineas Fung



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


Re: cache content survives a server restart

Posted by Aaron Smuts <as...@yahoo.com>.
There is no way to force items to go to disk and to
stay in memory.  If you set the memory max size to 0,
then they w ill all end up on disk.  If you set it to
10 and there are 100 items in the cache, then 90 will
end up on disk.  Chances are, that all of them will
end up on disk if the region is active.  The only way
to get all the items in memory on disk is to shutdown
the server.

When you shutdown the cache, the keys are written to
disk and the data file is defragmented.  The disk
cache tries to reuse empty spots, so defragmentation
is not that important on shutdown.  On startup the
cache will try to verify that the key file and the
data file are in sync.  If they are, then the data is
available. 

The indexed disk cache is fast because the keys are
stored in memory.  The key contains the location of
the item on disk.  The size of the item is stored on
disk, so we determine how much to read from the
datafile itself.

We could have a different kind of file where the keys
are also stored on disk.  We could then parse the
entire file at startup and pluck the keys from the
file.  This could make the startup times very slow for
large files, but it would allow some other tricks.

I'm thinking of a way to run in duplicated mode --
where the items will always be put to disk.  This
shouldn't be too hard.  We would need to decide if the
last access time for an item would be updated as well.
 If you get an item from memory, would we then then to
update the last access time of the item on disk as
well.  This would basically require another put to
disk for every get.  

The harder problem is getting the keys to disk. 
Currently, the disk cache does not use keys on disk.  

We would need to add another option to duplicate the
keys on disk.  This would start to get messy.

Aaron

--- Phineas Fung <ph...@hotmail.com> wrote:

> We're using JCS in a servlet environment, and want
> to see if we can have the 
> cache content survive a server restart.
> 
> Becoz the cache management module is very far away
> from the servlet class, 
> it's not very possible to pass a "shutdown" event to
> the cache management 
> module (so that it can invoke JCS.dispose()).  But
> on the other hand, we 
> want to have the cache content persists in a local
> file, and hope that its 
> content is always up-to-date, so that we can rebuild
> the cache from the file 
> when server restarts (e.g. after a crash).
> 
> Any insight will be greatly appreciated.
> 
> Thanks alot.
> 
> 
> Best Regards,
> Phineas Fung
> 
> 
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> jcs-users-help@jakarta.apache.org
> 
> 

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