Re: java.lang.OutOfMemoryError with WODisplayGroup
Re: java.lang.OutOfMemoryError with WODisplayGroup
- Subject: Re: java.lang.OutOfMemoryError with WODisplayGroup
- From: email@hidden
- Date: Thu, 09 Oct 2003 10:41:51 CDT
- Priority: 3 (Normal)
[demime could not interpret encoding binary - treating as plain text]
On Thu, 9 Oct 2003 15:21:16 +1300 Denis Stanton wrote:
> Hi Art
> I guess what I was hoping for (without really reasoning it out) was
> that the DisplayGroup would automatically figure out the SQL required
> to fetch only the records required to display the current batch. You
> don't need to explain the fallacy in this, I'm getting it.
Even though you said we dont' need to explain the fallacy, I'm going to
provide a few tips anyway, cause I think it'll help us come up with a
solution. The problme is really that there's no easy way to generate SQL
do what you're talking about. SQL doesn't really have anything like that
in it. One exception would be the 'cursors' that some dbs implement---the
problem is that in a typical WO application, multiple sessions and users
share the same connection(s) to the db, which makes cursors inappropriate.
There are various somewhat ugly ways to try to get ordinary standard SQL
to fetch in batches, using the "TOP X" directive. [At least my db
implements that syntax; other dbs may have other syntax, or not implement
the feature at all!]. The problem is that EOF doesn't have any
capabilities to use this "TOP X" syntax, so trying to use such syntax in
a WO/EOF application is pretty tricky; haven't figured out any really
good way to do it myself. But on top of that, if you are qualifying your
select with a WHERE clause anyway, it can be tricky to write logic that
even uses this syntax to do the right thing, not missing any rows when
they may change, etc.
Overall, you are better off figuring out how to avoid presenting the user
with thousands of rows anyway. Sure, the 'batch' system doesn't present
them with thousands of rows AT ONCE, but if they're never going to 'next'
to the 25th batch or whatever, what's the point of having the 25th batch
there anyway? Sure, alphabetic buttons is one solution---until you get
too many results even within a single alphabetic category! Personally,
I prefer to try and come up with some kind of a search mechanism, so the
user can search for just what they are looking for, by whatever criteria
will be useful in the problem domain. In my own search implementations,
I first check to see how many rows will be returned by the requested
search, and if it's over some maximum, I tell the user, sorry, too many
results, please refine your search. You can check how many rows will be
returned with SQL count(*)---there is a trick to using this SQL feature
well in a WO/EOF application; if you decide you need this, ask and I or
someone else will explain some ways to do it.
--Jonathan
>
> >> Is it really the case that a WODisplayGroup runs out of memory
> >> handling a table of between 3 and 6 thousand records?
> >
> > Nope, the JVM does.
>
> Fair enough
>
> > I guess the bottom line is that a Web application is generally used
> > by humans. Humans don't process thousands of objects very well. So
> > it's usually best to somehow limit the number of objects fetched
> > rather than to try to deal with a huge number of objects. Maybe
> > there's some sort of qualifier you can use to limit the number of
> > objects fetched. That would seem to be the preferable solution rather
> > than increasing the
>
> From a simple-minded user point of view, that's what the batch controls
> on the web page appear to be doing. They limit the amount of data
> being presented to the human. As you have explained, they don't
> limited the amount of data being presented to / handled by the
> WebObjects App.
>
> Darn
>
> In my application it looks like the simple work-around is going to be
> to display the alphabet A-Z across the page and ask the user to select
> one letter at a time, where that letter will be matched against some
> characteristic that is spread across the file. Probably the first
> letter of the customer name will be enough to break the file into
> chunks. This screen was only going to be used on rare occasions to
> locate historic information. I'm going to have to provide some
> alternative search methods, rather than just a batched list with
> multiple sorts, as I hoped.
>
> Thanks for your time
>
> Denis
> _______________________________________________
> webobjects-dev mailing list | email@hidden
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/webobjects-dev
> Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.