Well, this could be useful in many contexts, even outside of infinispan.
One thing to consider is the three ways things finish in Futures: completion, cancellation, and exception. I suspect the listener interface may want to handle all three, or some object that encapsulates those states.
I kindof like this flow in that case:
Future f = cache.putAsync(k, v).andInform(listener);
where NotifyingFuture has a method:
NotifyingFuture andInform(NotifyingFutureListener listener)
interesting stuff...
what do you think?
-Adrian
jclouds
On Sat, May 16, 2009 at 1:27 AM, Manik Surtani
<manik@jboss.org> 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()?
Sounds pretty useful to me. But just wanted to sound you guys on the API choices for notifications.
My immediate thought was to use the existing notification API. You register a cache listener, annotate a method with @RpcCallMade, receive an RpcCallMadeEvent. But this is probably pretty useless, since you couldn't associate the notification with the specific put you've just done. Even if you have the key in the event (which is unlikely - since we need to use the same event for all cache operations, some which take > 1 key such as putAll()), multiple threads could be working on the same key.
Another approach is to design a sub-interface to Future. NotifyingFuture.
public interface NotifyingFuture extends Future {
void addListener(NotifyingFutureListener l);
}
public interface NotifyingFutureListener {
void futureDone(Future f);
}
WDYT?
--
Manik Surtani
manik@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev