[infinispan-dev] Async Notification API

[David M. Lloyd]

On 05/15/2009 06:27 PM, Manik Surtani wrote:
> While the new async API has been getting rave reviews, someone did bring 
> up async notifications.  E.g.,
> 
>     Future f = cache.putAsync(k, v);
>     f.get();
> 
> But what if I don't want to wait on f.get(), I'd rather be told when the 
> future is done so I can do an f.get()?

In XNIO, I've solved this problem simply by using a new IoFuture type that 
can have notifiers registered on it, not unlike your NotifyingFuture 
example (which, by the way, works very well).

http://anonsvn.jboss.org/repos/xnio/xnio-base/trunk/api/src/main/java/org/jboss/xnio/IoFuture.java

Notice a couple of things that I learned the hard way. 
future.addNotifier() accepts a notifier and an attachment (allowing the 
same notifier to be reused by the user if so desired).  The notifier itself 
is called in any of three possible cases: success, cancellation (which may 
not apply to your use case), and failure.  The notifier has a single notify 
method which is called in any case (an IoFuture has a getStatus() method 
which returns an enum value).  There is an abstract class which has 
separate handleDone/handleCancelled/handleFailure methods, each with an 
empty default implementation; this allows users to easily create anonymous 
classes which only implement, say, handleDone, while still allowing a 
single method implementation which is called when any status change occurs.

Finally, the addNotifier method has a signature like this:

public interface IoFuture<T> {
   ...
   <A> IoFuture<T> addNotifier(Notifier<? super T, A> notifier, A attachment);
   ...
}

This allows users to register notifiers for IoFutures of any superclass 
type of the result.  This means, for example, that a Notifier<Object, ?> 
can be registered on any IoFuture, while a Notifier<Closeable, ?> can be 
registered on just about any IoFuture that returns an I/O entity (think 
async close after an operation completes).

One other lesson I've learned that may be useful to you even if you opt to 
stick with Future<T> is that you should always use Future<? extends 
Whatever> rather than Future<Whatever>, and encourage your users to do the 
same, which gives you a little more flexibility with respect to covariance.

While I doubt that IoFuture is directly applicable to your situation, 
hopefully you won't have to relearn the same lessons the hard way. :-)

- DML