org.hd.d.pg2k.webSvr.exhibit
Class AbstractFilterBean.MyObserver

java.lang.Object
  org.hd.d.pg2k.webSvr.exhibit.AbstractFilterBean.MyObserver

All Implemented Interfaces:

java.util.Observer

Enclosing class:

AbstractFilterBean

private static final class AbstractFilterBean.MyObserver
extends java.lang.Object
implements java.util.Observer

This object has only a WeakReference to the outer class to allow GC. This way it remains fairly safe for us to register with a DataSourceBean even if the outer class may be short-lived and churned in huge numbers.

FIXME: should find way to stop ourself from observing any DataSourceBean (there can be at most one) when the outer object is GCed or maybe when the cache is cleared. Else, lots of redundant (if small) MyObserver objects may accumulate in the DataSourceBean until the exhibit set changes.

beanWR

private final java.lang.ref.WeakReference<AbstractFilterBean> beanWR

WeakReference to outer class; never null.

AbstractFilterBean.MyObserver

AbstractFilterBean.MyObserver(AbstractFilterBean outer)

Capture a SoftReference to the outer class.

Parameters:

outer - non-null reference to outer class.

update

public final void update(java.util.Observable o,
                         java.lang.Object arg)

This causes the cache to be cleared immediately. If [Object] arg is an Integer whose value is same as the value that we hold for the DataSourceBean.ds.exhibitDataVersionHash() then we return immediately on the assumption that this indicates that we still hold an up-to-date cache. This avoids extra builds and clears of the cache when the FilterBean is accessed frequently, and in particular between the underlying data changing and a call being made sometime later to this routine to clear all potentially-expired caches.

We use [Observable] o to deregister ourself from the Observable on the grounds that our next select() operation will (re-)register us with whatever DataSourceBean we are then using. This removal avoids leaving references to us from multiple DataSourceBeans or after we have otherwise expired, which would otherwise make GC harder.

The cache-clearing code is synchronized so the caller may be briefly blocked and there may be a small risk of deadlocks if clearCache() does something foolish.

Specified by:

update in interface java.util.Observer