J2EE optimisation by pre-fetching pages

Question

Hi,
I´m working on a J2EE application/site that generates pages
dynamically. Although the pages vary significantly, the sequence of
pages for a particular user is generally predictable. The client is
worried about performance and wants the design to predict the next
page, generate and cache it, so that it is ready for the user´s
request.
The pages are, at base, JSP pages (whose content depends largely on
information in the user´s session that, over a single session, remains
constant). Is there any way to do what the client wants (with a
reasonable amount of effort)? I can't see how to work around the
demand-driven nature of a J2EE server (in this case Weblogic's).
Presumably, if there is a solution, it involves sending all requests
to a Servlet, rather than the JSP page directly, and somehow the
Servlet handles caching and prefetching. But that means the Servlet
has to fake a SessionContext and redirect it to the appropriate JSP
page (I think). Has anyone done this?
Thanks,
Andrew

Answer 1

Also, take a look at Tangosol's Coherence caching product:
http://www.tangosol.com/products-clustering.jsp
Peace,
Cameron Purdy
Tangosol, Inc.
Clustering Weblogic? You're either using Coherence, or you should be!
Download a Tangosol Coherence eval today at http://www.tangosol.com/
"Andrew Cooke" <[email protected]> wrote in message
news:[email protected]...
Actually, this reply is a bit too self-critical. It also makes sense for
this data to be inside the JSP page for other, more sensible, reasons too.
The data from page to page are very variable, requiring individual
formatting.
Andrew
"Andrew Cooke" <[email protected]> escribió en el mensaje
news:[email protected]...
Hi,
Thanks for the reply. Unfortunately it's difficult to know which data
to
cache until the page is generated, because the information that drivesthe
page generation is inside the JSP page, not the database. In otherwords,
when the page is generated, data within the page pulls the informationfrom
the database.
A cleaner design, obviously, would be to have everything in the
database,
but for practical reasons (limited resources - I am working for a small
company in S. America, with a tight deadline and no other Java/JSP
knowledge - that mean the closer this is to a "traditional" page-by-page
website, the more likely it is to work) this is not possible. Or, atleast,
it needs a very strong argument to change the approach (and I'm not sure
this is it).
Does that make sense? It means, as far as I can see, that only way to
prepopulate the beans is by pre-generating the page...
Thanks,
Andrew
<[email protected]> escribió en el mensaje
news:[email protected]...
Why don't you simply cache the data needed to render these
pages? Unless your rendering mechanism is slow by itself, for a
regular JSP which renders some pre-populated beans, pre-fetching
shouldn't make much (if any) difference.
Andrew Cooke <[email protected]> wrote:
Hi,
I´m working on a J2EE application/site that generates pages
dynamically. Although the pages vary significantly, the sequence of
pages for a particular user is generally predictable. The client is
worried about performance and wants the design to predict the next
page, generate and cache it, so that it is ready for the user´s
request.
The pages are, at base, JSP pages (whose content depends largely on
information in the user´s session that, over a single session,
remains
constant). Is there any way to do what the client wants (with a
reasonable amount of effort)? I can't see how to work around the
demand-driven nature of a J2EE server (in this case Weblogic's).
Presumably, if there is a solution, it involves sending all requests
to a Servlet, rather than the JSP page directly, and somehow the
Servlet handles caching and prefetching. But that means the Servlet
has to fake a SessionContext and redirect it to the appropriate JSP
page (I think). Has anyone done this?
Thanks,
Andrew--
Dimitri