 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | Page by Page Iterator | Page by Page Iterator 2003-11-21 - By Koala Gnu
Back
Kancharlapalli,Sridhar wrote:
> Hi,
>
> Let me try to elaborate some of my observations and solutions I
> applied in the projects I have done.
>
> We had similar problem as you mentioned, Large queries can be
> really be expensive as they deal with large data,this makes the
> ValueListHandler pattern hard to implement. And more over
> requering might induct or remove some of the previous results
> which might not be acceptable in all business process.
>
>
> Best way to do it is to get the initial results from DAO layer and
> cache them at the client and use a simple Iterator pattern for
> page navigation. To optimize the results you can retrieve only the
> key elements from DAO and cache them at client.
>
And you would do a complete query for only those set of records that are
to be displayed in the page.
>
>
Ok. This is the current solution used in my project but now we have the
following problem.
Suppose to have a Catalog C with a set of product P. Now consider to
have a find all
method on the ProductDAO the returns all the value objects Product.
This method is generally used in an internal timer task of the server
(so it is not used by the GUI).
Suppose P is a large set of products.
Since findAll is used internally by the server and the value objects are
not sent through the network, it is acceptable to use it.
Consider now to have a new requirement and the GUI has a new use case in
which all the products must be retrieved and showed page by page.
Our current solution is that the GUI retrieve only the primary keys of
the products and cache them. But from a server side I have to write a
new query. I cannot reuse the previouse one.
Now we are in the condition in which a lot of queries are duplicated
since in a case we retrieve all the objects and in other cases we
retrieve only the primary keys.
How I can avoid this?
Another question. If the GUI has a set of primary keys how I should
organize my code in order to allow the load of each single object?
Basically the question is if there is a description of this pattern on
the web.
Last question. Is it possible merge the two solution in only one? In
other words, I would like to use in some cases the Page by Page Iterator
pattern (and reuse most of the query used internally by the server) and
other cases the fetch of primary keys.
Thanks for your answer.
> -Sridhar Kancharlapalli.
>
> Hi all,
>
> Some questions regarding the page by page iterator pattern.
>
> I learnt how this patterns works looking at the petstore
> application. Then I tried to search on google a full description
> of this pattern, but I found only one document in spanish.
>
> First question. Can anyone of you send me a link with a full
> description of this pattern?
>
> Second question.
>
> I have a DAO layer which perform a specific JDBC query Q that
> returns a set of data of
> type T.
> Now I want display this result page by page. If I use the Page by
> Page Iterator pattern, the query Q will be executed each time the
> user switch from a page to another (each time the
> start point of the cursor in the Resultset will change). But this
> is not acceptable if the query is very expansive.
>
> I read a thread on theserverside.com but I do not understand what
> to do in this case.
> I think that the Page by Page Iterator is not appropriate in this
> case.
>
> Third Question. Is it possible combine the Page by Page solution
> with another pattern that is more appropriate for complex queries?
> In this way the client know that the result is paged
> but it do not know how this paging is implemented (Page by Page or
> other patterns).
>
> Thanks in advance for any help.
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
> http://java.sun.com/blueprints/corej2eepatterns List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
>
> ====================================================================
> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
> http://java.sun.com/blueprints/corej2eepatterns List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
> listserv@(protected)
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859 (See http://ISO-8859.ora-code.com)-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
<br>
Kancharlapalli,Sridhar wrote:<br>
<blockquote type="cite"
cite="midF35B6F97F73AB14CBA82C409472C73FA02853F@(protected)">
<meta http-equiv="Content-Type" content="text/html; ">
<title></title>
<meta content="MSHTML 5.00.3502.5390" name="GENERATOR">
<blockquote>
<div align="left" class="OutlookMessageHeader" dir="ltr"><font
size="2"><font color="#0000ff"><font face="Arial"><span
class="914142006-21112003">Hi,</span></font></font></font></div>
<div align="left" class="OutlookMessageHeader" dir="ltr"> </div>
<div align="left" class="OutlookMessageHeader" dir="ltr"><font
size="2"><font color="#0000ff"><font face="Arial"><span
class="914142006-21112003">Let me try to elaborate some of my
observations and solutions I applied in the projects I have done.</span></font>
</font></font></div>
<div align="left" class="OutlookMessageHeader" dir="ltr"> </div>
<div align="left" class="OutlookMessageHeader" dir="ltr"><font
size="2"><font color="#0000ff"><font face="Arial"><span
class="914142006-21112003">We had similar problem as you mentioned,
Large queries can be really be expensive as they deal with large
data,this makes the ValueListHandler pattern hard to implement. And
more over requering might induct or remove some of the previous results
which might not be acceptable in all business process.</span></font></font><
/font></div>
</blockquote>
</blockquote>
<blockquote type="cite"
cite="midF35B6F97F73AB14CBA82C409472C73FA02853F@(protected)">
<blockquote>
<div align="left" class="OutlookMessageHeader" dir="ltr"> </div>
<div align="left" class="OutlookMessageHeader" dir="ltr"><font
size="2"><font color="#0000ff"><font face="Arial"><span
class="914142006-21112003">Best way to do it is to get the initial
results from DAO layer and cache them at the client and use a simple
Iterator pattern for page navigation. To optimize the results you can
retrieve only the key elements from DAO and cache them at client. </span><
/font></font></font></div>
</blockquote>
</blockquote>
<font size="2"><font color="#0000ff"><font face="Arial"><span
class="914142006-21112003">And you would do a complete query for only
those set of records that are to be displayed in the page.</span></font></font>
</font>
<blockquote type="cite"
cite="midF35B6F97F73AB14CBA82C409472C73FA02853F@(protected)">
<blockquote>
<div align="left" class="OutlookMessageHeader" dir="ltr"> </div>
</blockquote>
</blockquote>
Ok. This is the current solution used in my project but now we have the
following problem.<br>
<br>
Suppose to have a Catalog C with a set of product P. Now consider to
have a find all<br>
method on the ProductDAO the returns all the value objects Product.<br>
<br>
This method is generally used in an internal timer task of the server
(so it is not used by the GUI).<br>
Suppose P is a large set of products.<br>
Since findAll is used internally by the server and the value objects
are not sent through the network, it is acceptable to use it.<br>
<br>
Consider now to have a new requirement and the GUI has a new use case
in which all the products must be retrieved and showed page by page.<br>
<br>
Our current solution is that the GUI retrieve only the primary keys of
the products and cache them. But from a server side I have to write a
new query. I cannot reuse the previouse one.<br>
<br>
Now we are in the condition in which a lot of queries are duplicated
since in a case we retrieve all the objects and in other cases we
retrieve only the primary keys.<br>
<br>
How I can avoid this?<br>
<br>
Another question. If the GUI has a set of primary keys how I should
organize my code in order to allow the load of each single object?
Basically the question is if there is a description of this pattern on
the web.<br>
<br>
Last question. Is it possible merge the two solution in only one? In
other words, I would like to use in some cases the Page by Page
Iterator pattern (and reuse most of the query used internally by the
server) and other cases the fetch of primary keys. <br>
<br>
Thanks for your answer.<br>
<blockquote type="cite"
cite="midF35B6F97F73AB14CBA82C409472C73FA02853F@(protected)">
<blockquote>
<div align="left" class="OutlookMessageHeader" dir="ltr"><font
size="2"><font color="#0000ff"><font face="Arial"><span
class="914142006-21112003">-Sridhar Kancharlapalli.</span></font></font></font
></div>
<div align="left" class="OutlookMessageHeader" dir="ltr"> </div>
<div align="left" class="OutlookMessageHeader" dir="ltr"><font
size="2"><span class="914142006-21112003"> </span></font>Hi all,<br>
<br>
Some questions regarding the page by page iterator pattern.<br>
<br>
I learnt how this patterns works looking at the petstore application.
Then I tried to search on google a full description of this pattern,
but I found only one document in spanish.<br>
<br>
<b>First question.</b> Can anyone of you send me a link with a full
description of this pattern?<br>
<br>
<b>Second question.</b><br>
<br>
I have a DAO layer which perform a specific JDBC query Q that returns a
set of data of <br>
type T.<br>
Now I want display this result page by page. If I use the Page by Page
Iterator pattern, the query Q will be executed each time the user
switch from a page to another (each time the<br>
start point of the cursor in the Resultset will change). But this is
not acceptable if the query is very expansive.<br>
<br>
I read a thread on theserverside.com but I do not understand what to do
in this case. <br>
I think that the Page by Page Iterator is not appropriate in this case.<b><br>
<br>
Third Question.</b> Is it possible combine the Page by Page solution
with another pattern that is more appropriate for complex queries? In
this way the client know that the result is paged<br>
but it do not know how this paging is implemented (Page by Page or
other patterns).<br>
<br>
Thanks in advance for any help.
====================================================================
Companion Site: <a class="moz-txt-link-freetext" href="http://www
.corej2eepatterns.com">http://www.corej2eepatterns.com</a> J2EE BluePrints:
<a class="moz-txt-link-freetext" href="http://java.sun.com/blueprints
/corej2eepatterns">http://java.sun.com/blueprints/corej2eepatterns</a> List
Archive:
<a class="moz-txt-link-freetext" href="http://archives.java.sun.com/archives
/j2eepatterns-interest.html">http://archives.java.sun.com/archives/j2eepatterns
-interest.html</a>
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
<a class="moz-txt-link-abbreviated" href="mailto:listserv@(protected)"
>listserv@(protected)</a> </div>
</blockquote>
====================================================================
Companion Site: <a class="moz-txt-link-freetext" href="http://www
.corej2eepatterns.com">http://www.corej2eepatterns.com</a>
J2EE BluePrints: <a class="moz-txt-link-freetext" href="http://java.sun.com
/blueprints/corej2eepatterns">http://java.sun.com/blueprints/corej2eepatterns</a
>
List Archive:
<a class="moz-txt-link-freetext" href="http://archives.java.sun.com/archives
/j2eepatterns-interest.html">http://archives.java.sun.com/archives/j2eepatterns
-interest.html</a>
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
<a class="moz-txt-link-abbreviated" href="mailto:listserv@(protected)"
>listserv@(protected)</a>
</blockquote>
</body>
</html>
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
|
