I was just given the committer status in JCS about 2/3 weeks ago , and thought I would start by suggesting/implementing a change to the cache API so that things will get simplified, unified, and paved the path to a much more powerful/elegant caching system. (I largely base my judgement on my working experience on our chacing system, which evolved from a "naive" API/impl to now a better/more scalable API/impl.)
But it seems it's just too hard (or too different from others), seeing the resposnes I get. Anyhow, the free time is now gone, and I probably won't be able to spend much time on JCS (except reading what others are doing) until probably after Oct. Hanson -----Original Message----- From: Stephen Haberman To: 'Turbine JCS Developers List' Sent: 7/27/2002 7:43 PM Subject: RE: possible application for jcs? Cool. I'll see if we can work JCS in to the picture then. You wouldn't happen to have any code that handles this sort of cached scrolling recordset that you'd like to donate to Torque, would you? :-) (I understand if it's a company proprietary thing, but I thought it'd be cool to see how your approach as it's working well in a production system.) Btw, sorry for posting this to the dev list...it should have went to user, but I had only signed up for the dev and didn't realize my error until it was too late. Thanks, Stephen > -----Original Message----- > From: Hanson Char [mailto:[EMAIL PROTECTED]] > Sent: Saturday, July 27, 2002 6:35 PM > To: 'Stephen Haberman '; '[EMAIL PROTECTED] ' > Subject: RE: possible application for jcs? > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
