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
>
This archive was generated by hypermail 2.0.0 : Wed Apr 14 2010 - 09:42:12 EDT