Andrus thanks for the info.
I am trying to get visibility into the effects of my configuration parameters. So if as you say, getDataRowCache().size() reports the number of "snapshots" and not the number of objects, the this is essentially reporting the number of hollow objects fetched. (I verified this with a test I did, in which I fetched a number of objects but did nothing to trigger a fault.) So what values (methods, classes, etc) do I monitor in order to find out the status of the cache (i.e. how many faulted objects, how many hollow objects over time)? (The reason I need this is: if I am going to start experimenting with query cache, and other parameters, it is important to monitor the effects.) Thanks, Joe On Apr 13, 2010, at 5:09 AM, Andrus Adamchik wrote: > > On Apr 12, 2010, at 5:10 PM, Joe Baldwin wrote: > >> I have tried to ask this question previously but did not see a response. > > Sorry, prolly missed your previous message. > > >> Assume default cache configuration, will the following call: >> >> >> ((org.apache.cayenne.access.DataContext)BaseContext.getThreadObjectContext()).getObjectStore().getDataRowCache().size() >> >> return the number of DataObjects in DataContext cache for a webapp (using >> standard configuration)? > > No. getObjectStore().getDataRowCache() returns a shared cache object used by > *all* DataContexts in the system (this assumes the default "on" value of "use > shared cache" checkbox for the DataDomain is not changed). Also it stores > "data rows", i.e. "snapshots" of objects, not the objects themselves. > > >> (The reason I am asking is that this number this method reports always grows >> during the life of the app, even on my dev server. I would have expected >> this value to get smaller once all of the sessions release references to the >> Select Query array lists, are nulled, and then GC'd.) > > Actually it is an LRU, so once it reaches a certain max size, it stays > constant. The default is 10000 snapshots and can be changed via a somewhat > misnamed "Size of Object Cache" field for the DataDomain in the Modeler. Just > don't set it to a value lower than an expected concurrent number of > uncommitted objects across all contexts in the system. > >> What should this number look like during the course of a well written >> webapp? Shouldn't the number go up and down depending on GC? (If there is >> a better method for visibility, please let me know.) > > Since it is an LRU, it should grow to the cache size limit, and then stay > constant. > > Andrus >
