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.
