It seems to me that most of the time, you are going to have a question and want
the answer before proceeding. Certainly the synch model is easier and cleaner
to program against (with the downside of blocking the calling thread).
Although you mention that it's easier to layer sync on top of async, I don't
think there's anything that would prevent you from providing sync now and
exposing async later as well.
I would rather err on the side of easy to program and explain right now and
open up for a non-blocking implementation later if it's needed.
While I can invent an async use case in my head, I don't see a compelling need
for it right now at the cost of complexity.
----- Original Message -----
From: "Geert Bevin" <gbe...@terracottatech.com>
To: "tc-dev" <tc-dev@lists.terracotta.org>
Cc: "Steven Harris" <st...@terracottatech.com>, "Alex Miller"
<amil...@terracottatech.com>, "Taylor Gautier" <tgaut...@terracottatech.com>,
"Sreenivasan Iyer" <si...@terracottatech.com>, "Ari Zilka"
<a...@terracottatech.com>, "Sergio Bossa" <sergio.bo...@gmail.com>
Sent: Friday, February 6, 2009 6:29:49 AM GMT -06:00 US/Canada Central
Subject: Async API for cluster meta data instead of sync
Hi,
While working on the new cluster events implementation of these
methods of DsoCluster:
Set<DsoNode> getNodesWithObject(Object object)
Map<?, Set<DsoNode>> getNodesWithObjects(Collection<?> objects)
<K> Set<K> getKeysForOrphanedValues(Map<K, ?> map)
I'm obviously going through our whole channel, messages, stages SEDA
infrastructure to communicate with the L2 and get the response back to
the L1. I'm currently working on blocking these methods until the
response from the server comes back.
This leads me to think that it might be maybe more useful to redesign
the API to be asynchronous with callbacks instead of blocking the
executing threads. It's always possible for users to adapt async to
sync, but not the other way around. I can definitely imagine
situations where it's more important to free the executing thread
immediately than to have the convenience of having a blocking response
as a method return.
The methods would then become:
void getNodesWithObject(Object object, NodesWithObjectsResult callback)
void getNodesWithObjects(Collection<?> objects, NodesWithObjectsResult
callback)
void getKeysForOrphanedValues(Map<K, ?> map, OrphanedKeysResult
callback)
With the callback interfaces something like:
public interface NodesWithObjectsResult {
void gotResults(Map<?, Set<DsoNode>> results);
}
public interface OrphanedKeysResult<K> {
void getResults(Set<K> results);
}
The methods could then be used like this:
cluster.getNodesWithObject(foo, new OrphanedKeysResult() {
public void gotResults(Map<?, Set<DsoNode>> results) {
// do stuff with results
}
});
Note that I just quickly typed these in the email, so there might be
typos/errors in the code.
What do you think?
Geert
--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Flytecase Band - http://flytecase.be
Music and words - http://gbevin.com
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
