The "ValueList Handler" pattern in "Core j2ee patterns(2nd ed)"
In the book "Core j2ee patterns(2nd ed)", it suggests that the "ValueList Handler" pattern can be used when the resultset from database is huge.
Basically, this is what it will do:
1) obtain a resultset from database query
2) cache the full resultset using a valueList
3) create a subList from the valueList
4) present the subList to the front end
To me, caching the full resultset in a valueList is no different from sending the full resultset to the front end. Both of them wasted a lot of resources. I am wondering why anyone would want to do the step(2) above. Why don't we go from (1) to (3) directly since we usually know which subset of the results the users are interested in even before we do the query.
[759 byte] By [
Galam_Ga] at [2007-9-29 17:45:21]
HiSame problem I also need to clarify. Please some one explain in detail which approach give high performance.BRSenaka
resultsets don't persist and tied to databse connections?
Another issue: open cursors on the database. This can lead to "socket leaks" where connections are not properly closed, etc. and pretty soon your database won't talk to anything...
> Hi
> Same problem I also need to clarify. Please some one
> explain in detail which approach give high
> performance.
>
>
> BR
> Senaka
Exactly, I don't understand why that "ValueList Handler" pattern qualified itself as a j2ee pattern since it has so much negative perfomance impacts.
On a website like Amazon, thousands of queries are performed daily. To cache the full resultset of every query simply wouldn't work.
I think the most efficient way is to write a disconnected resultset so it won't tie to the database. The disconnected resultset will only contains those data to be display on the front end.
I would really like to see somthing like the following in the JDBC API.
ResultSet rs = null; // some resultset
ResultSetFilter filter = null; // a filter to filter resultsets
// obtain a disconnected resultset from java.sql.ResultSet
DisconnectedResultset drs = DisconnectedResultset.filter(rs, filter);
// close the original resultset
rs.close();
In the above, anything that meets the condition specified in the filter will be stored in the disconnected resultset. After we created a disconnected resultset, it is safe to close the original resultset to release any database resources.
"DataListHandler" pattern
http://www.theserverside.com/resources/article.jsp?l=DataListHandler
http://www.theserverside.com/home/thread.jsp?thread_id=13939
article: ResultSet pagination using DB2, JDBC, and JSPs
http://www7b.boulder.ibm.com/dmdd/library/techarticle/0307balani/0307balani.html
> I think the most efficient way is to write a
> disconnected resultset so it won't tie to the
> database. The disconnected resultset will only
> contains those data to be display on the front end.
>
> I would really like to see somthing like the following
> in the JDBC API. [...]
>
Are you familar with Sun's JDBC RowSet ?
JSR-114: JDBC Rowset Implementations
http://www.jcp.org/en/jsr/detail?id=114
Related:
http://developer.java.sun.com/developer/Books/JDBCTutorial/chapter5.html
http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html
>
> Are you familar with Sun's JDBC RowSet ?
>
> JSR-114: JDBC Rowset Implementations
> http://www.jcp.org/en/jsr/detail?id=114
>
JSR-114 adds these interfaces:
javax.sql.rowset.CachedRowSet
javax.sql.rowset.FilteredRowSet
javax.sql.rowset.JdbcRowSet
javax.sql.rowset.WebRowSet
