Save the query parameters and reissue the command. Let the SQL engine cache
the results for you (most decent engines can out perform anything you cook
up).
We do this and serve up millions of hits a day from what is really a small
server, and every page is built dynamically.
Thor HW
----- Original Message -----
From: "Karanjit Singh" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 03, 2000 10:52 AM
Subject: Re: interesting one, 200 concurent users, large resultstes
> Craig R. McClanahan,
> Iam really thank ful to u for the time u devoted to answer my
> question.
> But my problem still remains I can have gibs of RAM but still I
> cant support the number of concurent users i want to support(in some cases
> can go upto 1000) and the some results can be million records.
> Regards,
> Karan
>
>
>
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: A mailing list about Java Server Pages specification and
> > reference <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Re: interesting one, 200 concurent users, large resultstes
> >Date: Wed, 2 Aug 2000 15:35:36 -0700
> >
> >Karanjit Singh wrote:
> >
> > > Yes i understand that i have to bring only 100 records to client
,
> >but
> > > when the client wants next 100 records from where will I get them on
the
> > > server(i can find them only if i saved them somewhere on my server ),
> >only
> > > way is to requery the database and that is even more expensive in my
> >case
> > > becuse iam using 3 tier system, so everytime goin back to database
> >server is
> > > very expensive.
> > > regards
> > > karan
> > >
> >
> >I had a similar requirement on one application, and followed this sort of
> >an
> >approach:
> >
> >* Run the middle tier on a system with gobs of real memory (for me it was
> > a gigabyte, which was cheap relative to the value of the application).
> >Devote
> > lots of it to your JVM.
> >
> >* As records are accessed from the database, cache them in a Java
> >collection
> > of some sort that is stored as a servlet context attribute (i.e.
> >application
> >scope
> > bean for JSP). For me, we had already designed JavaBeans that mapped
to
> > the underlying data so I cached the "bean" version rather than rows
and
> >columns
> > from a ResultSet. This also avoided any need to keep database cursors
> >open
> > for longer than necessary.
> >
> >* To make sure that the cache is up-to-date, run a background thread that
> >is
> > checking for cached rows that have been changed or deleted, or that
have
> >been
> > in the cache to long (the data I was dealing with was time-sensitive,
> >and has an
> > "interesting" lifetime measured in minutes to hours).
> >
> >* When doing a query, use the normal database facilities (some of my
> >"where"
> > clauses got quite intricate) to make sure that the results are always
> >accurate
> > no matter whether the actual data is cached or not). BUT, retrieve
only
> >the
> > primary keys of the result records. Now, of that set of keys, some of
> >the
> >records
> > are already in the cache and some aren't. For the ones that are, just
> >add
> >references
> > to them to an ArrayList or Vector. For the ones that aren't, go read
> >them from
> >the
> > database (and cache them) as you add them to the list.
> >
> >* As you do update transactions, be sure that you update the cached
version
> >of the
> > information as well as the underlying database.
> >
> >The net effect of all this was that the cache contained the data that has
> >been
> >retrieved or modified recently, which tended to be accessed frequently
for
> >a while
> >and then not at all later. This works pretty well as long as you can
> >afford enough
> >memory to keep this "recently accessed working set" of data in the cache,
> >which was
> >true for me. It also let me scale to multiple middle tier servers that
> >accessed
> >the same back-end database -- primarily because I did not require
> >up-to-the-second
> >accuracy of the search results, so I could ignore the issue of
> >synchronizing the
> >various caches.
> >
> >I hope some of these ideas might be useful in your app design.
> >
> >Craig McClanahan
> >
>
>===========================================================================
> >To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
> >JSP-INTEREST".
> >Some relevant FAQs on JSP/Servlets can be found at:
> >
> > http://java.sun.com/products/jsp/faq.html
> > http://www.esperanto.org.nz/jsp/jspfaq.html
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
> ________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
>
>
===========================================================================
> To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
> Some relevant FAQs on JSP/Servlets can be found at:
>
> http://java.sun.com/products/jsp/faq.html
> http://www.esperanto.org.nz/jsp/jspfaq.html
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
> http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
>
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
