Updating TableModel in a thread...

[FET]

Hi,
I have a large number (over 100,000) records in a resultset, which I
would like to display in a JTable. I have extended the
AbstractTableModel and implemented the necessary methods. The problem
is that loading such a huge amount of data takes a lot of time.
So I used a thread to load the data into the Vector (Abstract Table
Model). But I would like to filter the data depending on user's
selection (after all the data has been loaded). So when I try to edit
the items in the Vector to filter it out, I get a
java.util.ConcurrentException. I have synchronized the methods in the
table model, but to no use. Also the GUI becomes very slow when this
table loads, even though it is loading in a separate thread.
Is there any other (less performance penalty) way of showing a large
amount of data in a JTable ?
Thanks in advance!
Best regards.

 

[Harish]

i dont have an answer...but i think 100,000 records in a GUI will not help a
user...
scrolling through so much data, making selections etc will just confuse the
user....
i am sure you can come up with a better way to display the data, wthout
sacrificing user experience....
just a suggestion.

 

[Filip Larsen]

FET wrote

I have a large number (over 100,000) records in a resultset, which I
would like to display in a JTable. I have extended the
AbstractTableModel and implemented the necessary methods. The problem
is that loading such a huge amount of data takes a lot of time.
So I used a thread to load the data into the Vector (Abstract Table
Model). But I would like to filter the data depending on user's
selection (after all the data has been loaded). So when I try to edit
the items in the Vector to filter it out, I get a
java.util.ConcurrentException. I have synchronized the methods in the
table model, but to no use.

I assume you mean ConcurrentModificationException, which is something
you get when you iterate over a container that has just been modified.
It has nothing special to do with using multiple threads, and using
synchronized is meaningless here. Read the documentation on
ConcurrentModificationException for additional details.

The classical single-thread example is when you iterate over a container
and for some elements try to remove them from the container:

Collection col = ...
for (Iterator i = col.iterator(); i.hasNext(); ) {
Object element = i.next();
if (shallRemove(element)) {
col.remove(element);
}
}

Here you will get a ConcurrentModificationException on i.hasNext() after
the first time an element has been removed. In this particular case the
way to remove the element is to use Iterator.remove() instead of
Collection.remove() or similar.

If you want to add elements while iterating you will have to either
iterate over a copy of the container you add to, or you will have to
make a list of elements to add while you iterate, which you then add in
the end with Collection.addAll() or similar.

Also the GUI becomes very slow when this
table loads, even though it is loading in a separate thread.
Is there any other (less performance penalty) way of showing a large
amount of data in a JTable ?

If you don't want to load too much data you can filter out the rows you
don't want right in your SQL queries so that only wanted rows are
fetched in the first place. If the user makes a change in the filtering
condition a new query is made and new rows are loaded. You can also
combine this with internal filtering. For instance, I have an
application where rows are fetched when the user selectes a date but all
remaining filtering is done internally once the rows for that date is
fetched.

A different option is to use a scrollable ResultSet. With that you only
fetch a fixed number of rows (say 100) even if the query selects 100000
rows. This means that the ResultSet remains open while the user is
viewing the data and when he scrolls up or down more rows will be
fetched. This solution requires a special table model that can translate
the scrollable ResultSet into a vector, or perhaps a non-JTable GUI
component that only allow page up and down. If combined with the above
mentioned query-on-filter-change you almost have a standard database
table browser functionality, which I bet you can find off-the-shelf
somewhere.


If neither of these approaches appeal to you there are also other ways
of increasing percieved GUI-performance.


Regards,