Value List Handler

Hi,

I am designing an application that will provide a web service front end to query AS/400 data. The web service will access a stateless session bean that will call a DAO to execute the query on the AS/400.

The queries will be made up of varied search criteria and will be specific to a set of permissions. Some of them could return thousands of rows.

My thoughts on using the ValueListHandler pattern for our scenarios:

Result sets are returned from the database as a result of running a query.

Result sets cannot be cached as they require connections to the database.

In order to cache data returned in manner suggested by pattern, we would have to create an object for each row in result set (potentially thousands), add them to a valuList and cache.

The cached valuelist could only be reused when permissions and search criteria are identical to those used in original search so this data would also have to be stored along side cached value list and checks performed before deciding to use cached data or run a new query.

Alternative suggestion:

Run query each time against database (using native driver between Java app and database so there will not be a large network overhead)

Only create objects for subset required, e.g., 10 - 20. Can use resultSet.absolute(10) to get directly to 10th row in result set.

Only need to process 10 rows at a time, do not need to create objects for thousands of rows (most of which will potentially never be accessed).

Could cache these 10 objects if required but possibly no reason as same query (identical permissions and search criteria) will hardly be entered that frequently in a short time peroid.

The downside to my alternative suggestion is that the Database will be constantly hit with queries but is this not more acceptable than creating thousands of potentially unused objects and maintaining them?

Advice would be greatly appreciated..

Thanks.

[2001 byte] By [aedemar] at [2007-9-27 19:11:02]
# 1

Hello aedemar,

We faced a similar scenario a few years back on a project we did. I think the deciding factor for us was the requirement of applying the authorization restrictions. For us it would have been very difficult to maintain a cache and still enforce the authorization restrictions so we decided to do an implementation that is almost identical to your alternative suggestion.

The project that I'm talking about was a rental management system. Some example queries were -- give me all rentals where the renter's first name is Mark. But because of the authorization restrictions, one user running this query would normally obtain a completely different set of rental records than another user running the same query. This made the prospect of maintaining a cache pretty unapealing -- expensive in terms of development and maintenance and resources for not much (if any) performance improvement.

Hope this helps a little. This is a difficult question because it is not the typical case. You have to weight the benefits that you think you can get from caching in your specific case. Would you get any benefits? You probably would only get benefits if users with the same security authorization rights were performing the same queries close together in time (close enough in time so that the cache did not expire).

--Maciej Zawadzki

mbz@urbancode.com

http://www.urbancode.com

maciejz at 2007-7-6 21:34:35 > top of Java-index,Other Topics,Patterns & OO Design...
# 2

Hi,

I can point these things as per my understanding and experience

1)If you have all the tiers on different physical machines then the caching will be usually appropriate even with huge searches.Moreever in cahing you have to take care of the cache updates...

2)If you have single physical system then avoid caching,better to make lots of hits to DB and let allocation maintained...

Waiting for your opinion

regards

Vicky

vickyk at 2007-7-6 21:34:35 > top of Java-index,Other Topics,Patterns & OO Design...
# 3

Hi,

I can point these things as per my understanding and experience

1)If you have all the tiers on different physical machines then the caching will be usually appropriate even with huge searches.Moreever in cahing you have to take care of the cache updates...

2)If you have single physical system then avoid caching,better to make lots of hits to DB and let allocation maintained...

Waiting for your opinion

regards

Vicky

vickyk at 2007-7-6 21:34:35 > top of Java-index,Other Topics,Patterns & OO Design...