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
