If you are making a big query like this, regardless of pagination, the next
time you request that data from the database it is likely to be in the cache
assuming the user doesnt go for coffee in the meantime.
Alternatively you could use an entity bean or other persistant singleton
object to do this caching/returning subsets. All you would need to store in
your
HTTP session would be the index and the query object, and again access would
be quick assuming the entity bean didnt need to be serialized.
Of course I should probably follow that up saying that I haven't found a
*good* case for Stateful session beans yet barring large transactional
systems, so my
opinion may be somewhat suspect.
The classic example (Sun's shopping cart app) could be done quite easily
using HttpSession data. It really amounts to the same (or less, since there
is container overhead) memory requirements and less cpu usage (since you
aren't having to serialize/deserialize and go through the ejb layer each
time you query the data). This would be pretty important for any shopping
app, since they typically need to handle a lot of concurrent sessions.
Just my 2c,
-David
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of David Wall
Sent: Thursday, June 22, 2000 9:05 PM
To: [EMAIL PROTECTED]
Subject: Re: HTTP Session Vs Stateful Session Beans
> And a question... Are you trying to make this big query, and then split
the
> results to show a small amount of them in every 'screen'...
> because if so, what you need is PAGINATION, that is, to be able to split
> your big query into smaller querys (like altavista does to 'show' a
million
> hits... ten a page..)
But is there really any good scheme for pagination with an SQL DB? Some DBs
have a LIMIT clause, but still there's a good chance the entire result set
has to be retrieved before the subset is returned, unless the DB has nice
optimizations and the WHERE clause is on an indexed field.
David
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
