I think the key is "accessed frequently and seldom changed". I think it is alright to jam a bunch of objects into the cache as long as it is helpful to do so. As long as you got the memory pile it on. I think what I was pointing out had more to do with the lack of control over the cache that OJB provides. 500 objects is actually not a big deal. But, if they are seldom accessed it's a waste of memory. OJB is an all or none cache. You can't decide about caching one object set from another. It caches everything or nothing. This produces problems for administrative areas where you want fresh database calls to happen. You can clear the cache in OJB. But, it winds up clearing EVERYTHING and now you have to work the processor to get your object cache back up. Kinda defeats the point of caching... don't it?
Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -----Original Message----- From: Steve Gass [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 25, 2003 5:06 PM To: Struts Users Mailing List Subject: Re: Struts and OJB On Saturday 25 January 2003 15:24, Brandon Goodin wrote: > Say you load a Category Object and that Category contains > 500 items and those 500 items contain on the average of 20 bullet > points. If you are not careful about how you are coding it you will > have 500 Category objects cached in memory along with all of it's > nested objects. That is a lot of overhead to be storing in a cache. I'm curious about this sort of thing. In the case of objects which are accessed frequently, but seldom change, is 10,000 really all that many? I started up the default install of Resin in jProfiler and clicked through some of the docs and examples. By the time I got bored there were over 250,000 objects in memory, and forcing garbage collection didn't have any effect. Resin was using about 72 megs of RAM. Assuming that sufficient RAM is available, at what point does storing objects in memory become less efficient than creating them each time they're needed? Thanks. Steve -- 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]>
