Take a look at the HttpSessionBindingListener in the javadoc that comes with
the JSDK.
(*Chris*)
----- Original Message -----
From: Jaganathan Jeyapaul <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 27, 1999 6:30 PM
Subject: Re: Caching resultset at the server side..
> Hi Randy Belknap,
>
> Thanks for your extensive reply.. i think i am going to cache the
resultset
> as temp files and then flush them out periodically or when the session
> expires.. But again i never get to know when the session expires..
>
> jagan j
>
> -----Original Message-----
> From: A mailing list for discussion about Sun Microsystem's Java Servlet
> API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of Randy
> Belknap
> Sent: Monday, September 27, 1999 5:50 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Caching resultset at the server side..
>
>
> I know of four different ways to accomplish this and have implemented
> two of them myself (1 and 2 below). It seems like a common requirement
> that doesn't have a very elegant solution.
>
> 1. Cache the results of the query in your app (e.g. as a List you store
> in users session) and when the user hits the more button you retrieve it
> from the cache. A variant on this that I use is to read a fixed number
> of records from the database (e.g. 100) no matter how many records match
> the criteria. The user can scroll until they get this number and then
> the more button is replaced by text asking them to narrow their search.
> Even though I'm only reading 100 records, I do a count on the same query
> so the user sees the accurate number of results (e.g. 20-30 of 24143).
> The downside of this method is that it stores the results in memory
> which won't work for huge traffic sites.
>
> 2. Cache the SQL and re-execute it each time the user presses more.
> (Of course you skip the first n records). I think this is the method
> described in the early response. The downside is that it will behave
> oddly if the database gets updated while the user scrolls. E.g. when the
> user presses previous he/she could see records that weren't originally
> included.
>
> 3. Use Oracle's temp table feature. This is what you would probably do
> if it was client/server app. You store the results of the users query
> in a temp table and then navigate back and forward through that table.
> The temp table is typically smaller than the original set and does
> involve any joins. The problem with temp tables is that they are
> created based on the Oracle user id and are automatically cleaned up
> when the user logs out. That will not work so well with connection
> pooling. You'd have create your own naming and clean up scheme.
>
> 4. Use a text file in place of a temp table. You write the results of
> the query to a text file then read from that when the user scrolls.
>
> > Hi All,
> >
> > I am fetching thousands of results from the database based on user
query.
> > But i need to show just few of them to the user and cache the rest at
the
> > server side. If the user wants to see more results then the cached
> resultset
> > should be queried and served to the user..
> >
> > my question is what is the rightway to cache information (fetched from
> > database..) at the server side..
> >
> > Could someone me suggestions or pointers to the right direction..
> >
> > I am using JSDK 2.1 / WEBLOGIC / JDBC.
> >
> > Thanks in Advance..
> >
> > ==================
> > Jagan J
> > Java Consultant
> > ==================
> >
> >
>
___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
> >
>
___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
> >
> >
>
___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
>
___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
