Skip to main content

AsynchronousFilter added

5 replies [Last post]
bryanyoung
Offline
Joined: 2004-07-05
Points: 0

I just checked in AsynchronousFilter to the incubator. There's a demo to play with, although I'm more interested in feedback about the code:

https://jdnc-incubator.dev.java.net/demos/bryanyoung/AsyncFilter/AsyncFi...

The basic idea is that the filtering happens on another thread. The filter tries to wait for the filtering to complete before moving on. If the filtering hasn't completed after 200 mills, it hands off to the next filter and stops blocking the event thread. When filtering is done, it notifies downstream filters again with the updated results. In the time between the event thread unblocking and the filter results being completed, the filter is returning invalid data (which is then corrected as soon as processing completes).

I'm not sure how robust it is at this point. I've done this in the past using table models. That implementation worked fine for dozens of tables before we ran into some pretty obscure issues. This model is different enough that those past issues don't really apply. I figured I'd get some feedback before spending too much time running it through the ringers.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
ghantaprasad
Offline
Joined: 2007-06-21
Points: 0

could you please send me code sample for "Asynchronous Filter" on JXTable.

My requirement is : I need to apply random filters on same column ,based upon user action.

I think , as of my knowledge , we can't change existing pipeline filters . I would like to know how it is being applied to single column.

reden
Online
Joined: 2004-01-02
Points: 0

Nice! Now we're talking! I'll have to try this out. Will this also work with sorting?

As far as returning invalid data, it would be nice if it returned the result before the filter change was made until it completely refilters. Also, can you get notifications about when filtering is beginning and ending (for status notification)?

bryanyoung
Offline
Joined: 2004-07-05
Points: 0

> Nice! Now we're talking! I'll have to try this out.
> Will this also work with sorting?

I hadn't even noticed a problem with sorting until you mentioned it. I haven't looked at how sorters are implemented, but since a Sorter is a subclass of Filter, I imagine the problem will be very similar. I'll wait until I get a little feedback from the filter (to make sure I'm going the right direction), and throw a AsynchronousSorter together.

> As far as returning invalid data, it would be nice if
> it returned the result before the filter change was
> made until it completely refilters.

Returning the results from before the filter change would require keeping a copy of that data. Currently, I just keep a map of references to the original data.

Copying the data is a problem because a table model can contain any kind of object. When you're dealing with a table of Strings, everything is simple; but a generic solution would be complicated.

> Also, can you get
> notifications about when filtering is beginning and
> ending (for status notification)?

I have a note in the code about that. I figure some people may want to disable selection changes to the table, or make some other UI changes while filtering is running so the user doesn't get confused when the table refreshes again.

Jesse Wilson

On 10/4/06, jdnc-interest@javadesktop.org wrote:
> Returning the results from before the filter change would require keeping a copy of that data. Currently, I just keep a map of references to the original data.

Make sure to put bold warnings about the lack
of thread-safety of this approach. There's a bunch
of potential problems that can happen:
- the tablemodel changes during a filter
- the data in the tablemodel changes during a filter (ie mutable cell values)

Without locks, the solution is inherently dangerous!
I recommend following an 'optimistic locking' approach:
1. Install a TableModelListener that records if
the TableModel has changed
2. Within your invokeLater() that updates the table
with the new filter results, consult your record
of whether the TableModel has changed since
filtering has started. If it has, throw away your filter
results and restart!

Regardless, I think async filtering is a powerful weapon
in the fight against slow UIs.

Cheers,
Jesse

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

bryanyoung
Offline
Joined: 2004-07-05
Points: 0

> I recommend following an 'optimistic locking'
> approach:

I think that would be a good description of what I'm doing. My implementation is a bit different than you describe, but I think it has the same effect.

> 1. Install a TableModelListener that records if
> the TableModel has changed

The JXTable is listening to its model and triggering a Filter.refresh() on any table changes.

> 2. Within your invokeLater() that updates the table
> with the new filter results, consult your record
> of whether the TableModel has changed since
> filtering has started. If it has, throw away your
> our filter
> results and restart!

Because refresh() is called on each known table change, the first thing I do when my filter is called, is discard any currently running thread. The results of that thread would only have been applied to the filter if they had completed without interruption. If the thread is interrupted, then it means there will shortly be restarted with fresh data, and any stale data in the filter will soon be replaced.