What is the size of your object cache? Look under the DataDomain. If
it is a large number, try lowering it.
On Thu, Sep 17, 2009 at 2:18 PM, Joe Baldwin <jfbaldwi..arthlink.net> wrote:
> Michael,
>
>> With a paginated query, Cayenne fetches all of the PKs in (500-5000), but
>> then only fetches one page of data objects (say 10, using the PKs it fetched
>> previously) as you are looking at them, which will be more efficient for
>> large sets where you don't use all of the data at one time.
>
> Yes this is a really good idea. I have been using it for the past few
> months now. However, I was also using caching (which your docs say
> interferes with BaseContext "weak reference" memory management).
>
> My initial plan was to cache the products that are simply being looked at by
> customers. However, I thought that might be a problem if as customers look
> different products the cache will simply grow until it runs out of memory.
> So I am not sure if this is a good idea anymore. Is this cache ever
> released after a period of time?
>
> Second, I am investigating a comment by the Webhost tech support, who said:
> "watch out for singletons". Well the only thing that might be a problem
> that I have done is to implement a Factory class, which is essentially a set
> of class methods that I have written to accomplish to most repeated fetches.
> Would these fetches using static methods (I use only local variables in
> these static methods) cause any problems with BaseContext memory managment?
>
> So, if these are not the problems then I guess all I can do is increase the
> Xms.
>
> Thanks,
> Joe
>
>
>
>
>
>
>
>
>> If you are fetching 500-5000 products at a time, I'd seriously
>> consider using pagination since it is unlikely they will look at
>> 500-5000 products at a time. On your SelectQuery object, do a
>> setPageSize(10) -- or some other reasonable number (how ever many
>> products you show on one page). This will reduce the memory
>> footprint. See:
>>
>> http://cayenne.apache.org/doc/paginated-queries.html
>>
>> With a paginated query, Cayenne fetches all of the PKs in (500-5000),
>> but then only fetches one page of data objects (say 10, using the PKs
>> it fetched previously) as you are looking at them, which will be more
>> efficient for large sets where you don't use all of the data at one
>> time.
>>
>> As for one context/application, this is not what the thread context
>> (which you are using) does. The Cayenne filter creates or restores a
>> session-based context that is kept around for that user for the life
>> of the session. For some applications this makes perfect sense. You
>> might want to keep their shopping cart objects around from
>> request-to-request, for example. For a catalog type application,
>> though, I personally would probably use a brand-new context in each
>> request for fetching catalog data, letting it go at the end of the
>> request. This will allow those contexts and data objects to be
>> garbage collected much sooner. When needing to copy something from
>> the temporary catalog context to the user's session context (because
>> Cayenne needs related objects in the same context), you need to use
>> localObject():
>>
>> http://cayenne.apache.org/doc/moving-objects-between-contexts.html
>>
>> I know that was long-winded, but I hope it gave you some ideas.
>>
>> Also, you said, "I do not want to do this if this is not your normal
>> procedure." There isn't really a normal procedure. Each application
>> has requirements that drive how you approach it. In one application I
>> kept 10,000+ records in an application-level object that was shared by
>> all sessions. These records were read-mostly and expensive to read in
>> (required several minutes due to the number of joins) and I cached
>> them and controlled access to them. This approach made sense -- for
>> that application.
>>
>> mrg
>>
>> PS. Add the paginated queries first and see how much that buys you.
>> That should be easy to do. Changing the way you are using the context
>> will be much more time consuming.
>
>
This archive was generated by hypermail 2.0.0 : Thu Sep 17 2009 - 14:28:04 EDT