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(a)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(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev