Any views on this, anyone?
Please can you tell me if the following is an appropriate use of JCS.
My application will ultimately be long running and I want all the classic
features of a memory based cache that spools to disc. However, I want to
use JCS during the development cycle and then leave it in-situ ready to be
used in the finished application.
My application processes data through stages A > B > C > etc and I intend
storing objects in a cache at the end of each completed stage. In JCS
terms, I would give each processing stage its own region.
In development, I am developing the stages sequentially A,B,C... and
continually stopping and starting the JVM as I develop the later stages of
the process pipeline. I want to be able to re-use data successfully
processed and stored in the cache from earlier stages.
1) My application only runs for a short time, in development, and runs
100% cpu. In my limited testing of JCS so far, I find that any lazy
spooling to disc does not occur. Indeed, spooling to a Disc Cache only
occurs if MaxObjects is exceeded. What I would like is a command that
could be executed that spools all memory objects to disc on a
blocking-call basis (so that the JVM can exit knowing that the spooling is
complete)? I suppose this is equivalent to EJB passivation of entity
beans when you shutdown a server gracefully, or a JSP server that persists
sessions.
2) If I change the class signatures of data previously stored at any
stage; how do you suggest I deal with this? Are these appropriate: I can
remove all data from the region (that caches that set of classes), or trap
IncompatibleClassChangeError type errors as the cache is read.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
