JDBC Resultset Cache

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

> I figure I should put a jdbc resultset cache, and have seen discussions about CachedRowSet.

you don't need that.

By the sound of it your problem is caused by your model querying the database to get table values.
Instead you should query the database one to get the table data, and use that data to populate your table model

ASKER

From reading the article, CachedRowSet is not really a cache, it's a complete copy. (A cache would keep recently accessed data locally to speed up the operations).

My current table model does one query, and uses the resultset to get table values. The query can return, say, 30,000 records, so I wouldn't want to download 30k records, just 12 or 15 to fit the screen (and maybe a little more in the background, but that would be more advanced!).

I'm looking for a simple way of doing this. My resultset has record #'s, so I can always cache the results manually (look to the cache before reading the resultset), but don't want to reinvent the wheel. There may be something that will do this more transparently.

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

ASKER

It's the pre-invented wheels that I'm looking for.

For example, the resultset provides many routines--getInt, getXXX, putXXX, etc., I certainly don't want to provide all of these routines. And solve all the gotcha's that others came up with.

Perhaps I should also ask a question from another forum, maybe java EE or network people would have ideas how to speed the app up (possibly without even changing the code!)

Any ideas?

Or maybe database peope also

Maybe you need to check if you have appropriate indexes on the table?

ASKER

It's not the indexes, it runs very well on a local network, it already has the resultset. The scrolling through the resultset is slow.

> My current table model does one query, and uses the resultset to get table values.

That sounds like your problem.
You should be querying the database (in the background) as needed. For example loading a 'page' at a time as needed.

> (possibly without even changing the code!)

maybe, but by the sounds of it the problems in your code

> The scrolling through the resultset is slow.

scrolling thru a resultset over the network *will* be slow

I'm not sure of the details but your big resultsets will not be sitting on your local machine I believe, it all depends on how driver accomplishes it. Maybe somehwere on that level there is some resource to speed it up. Otherwise iterating through resultset shouldn't be longer thathrough hashtable.

So how do you deliver the data for a particular cell of the table? Maybe you can post one of the methods?

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

SOLUTION

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Guy Hengel [angelIII / a3]

ASKER

The tablemodel and the fetch size look promising and simple, I will try these and report back.

I've requested that this question be deleted for the following reason:

This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.

ASKER

I will close this question myself and award points. Please cancel the "auto cleanup".

ASKER

I will close this question myself and award points. Please cancel the auto-cleanup.