Hello Fred, I think you could write your own implementation of a DataModel for your need I think. It simply has to support lazy fetching and maybe release rows after they're read? This should be transparent to all other parts of the application as well as the user except for a slower loading time as data won't be cached. Again, the memory/time compromise holds true.
Regards, ~ Simon On 12/18/06, Jeff Bischoff <[EMAIL PROTECTED]> wrote:
Fred, Are you using JSP or Facelets? They tend to have different performance. Myfaces wrote: > Hi, > I've been using Myfaces implementation of JSF for couple of months but > didn't perform profling and facing issues with memory footprint now. > I'm using t:datatable for rendering employees info. Each row corresponds to > a employee object, the row has 10 columns. > It works fine in terms of memory footprint and CPU, when the dataset the > table renders is small, but when the size of the datasets is large(talking > about 1000 or more), I get Out of memory error even though the Managed Bean > is request-scoped. No pagination being employed(that's the last resort - > > as the users get annoyed with it). So when the number of user increases, > this leads to a serious issues of server crash, hang etc. > On profiling using yourtoolkit, I found that faces context never releases > the memory used by UI Components and the behaviour is erratic. The GC kicks > in after certain stage which is not very useful. Even for a table of small > data rows(20-30), it doesn't seem to release the memory. > So even the pagination doesn't seem to solve the out- of- memory issue as > the web site will be used by at least 4000 users. Also the > STATE_SAVING_METHOD is client. > > <context-param> > <param-name>javax.faces.STATE_SAVING_METHOD</param-name> > <param-value>client</param-value> > </context-param> > > Has anyone faced similar issues? Would appreciate your help in this regard. > thanks > Fred >
