[infinispan-dev] Async Notification API

[Manik Surtani]

Hi David

Yes, this does look good - I have started a discussion on concurrency- 
interest on the subject as well.  You should contrib these thoughts  
there as well.

Cheers
Manik

On 18 May 2009, at 15:07, David M. Lloyd wrote:

> 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

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org