We've done this all the time with our caching system in our production system, using RAM-DISK-REMOTE cache. The use of RAM along is not good enough as there is no upper bound to the cache item total size. The use of DISK is justtified as the direct access time to the file system is way faster then the time of querying the db.
Serializable is actually desirable in such cases, to the very contrary. And experience shows it works really well. We also have a hard/soft reference hybrid cache in our remote cache system, where the soft cache items are dynamically removed according the the JVM memory need. (Hard item by definition must stay in memory/disk.) Hanson -----Original Message----- From: Stephen Haberman To: [EMAIL PROTECTED] Sent: 7/26/2002 11:41 PM Subject: possible application for jcs? Hi, A Torque user, Scott Eade, has submitted a patch for Torque to deal with paging through large chunks of database rows. It's got a lot of logic to deal with what rows to keep in memory and when it needs to go fetch some more. I had the thought while reviewing his patch that perhaps JCS could be used as the store? My hesitation is that it would involve a fair amount of puts...say getting 5-6 page blocks at once (with, say, 100 rows per page), putting them all in memory, then waiting a few seconds/minutes for the client to work through those, then putting another 5-6 pages blocks in memory, etc. Would this be too many writes to make JCS effective? For what it's worth, I couldn't for see using any type of disk/network cache, it'd be primarily in memory only. (Perhaps this is a good application where Serializable wouldn't be desired, but only wanting to keep non-serializable Objects around for so long). Thanks, Stephen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
