Hey John, I think we talked about this on irc. Orion's finders just aren't flexible enough to fetch only a subset (unless you can create your own index and keep track of it). I see two options: use TopLink since it has a lazy- fetch cache, but I'm not sure how easy it would be to get TopLink to work with Orion. Or, write a stateful session bean that performs a raw JDBC query. It should be stateful to keep track of your index into the record set between calls to the bean. The only think ugly about this is you've just put db-specific jdbc stuff in a bean. -tim > -----Original Message----- > From: John D'Ausilio [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 07, 2000 6:00 PM > To: Orion-Interest > Subject: Large Collections > > > We're working on an ecommerce site which has a rather large > (> 3M) record > products table. We were hoping that the Collection which is > returned when an > entity bean's collection field getter is called would be > smart .. that the > entity beans would be instantiated as needed vs all > instantiated at once. > Alas, it appears that this is not the case. I initially ran > out of memory > trying to get the collection until I applied the > ApplicationAdministrator.flushEJBCache hack, but the elapsed > time is still > just too large when dealing with that collection. > > My question is how are people handling this kind of problem? > Should I just > abandon CMP for this stuff and do it in a traditional > fashion, perhaps a > temporary table, via JDBC? Maybe cache the handles from the > CMP collections > for reuse? Go for a database specific solution? > > tia > > john d > >
