In the previous two parts I covered the background of XOTS, using a basic tasklet to return a result, and using a basic tasklet to run a background task allowing the user to continue working with the application while the background task completed.
In that example the background task did not take a huge amount of time, so it might be worth waiting for the task to complete. But it was iterating over all the states and getting a list of names for contacts in those states. Wouldn’t it be more efficient if we processed different states simultaneously, so making the tasklet multi-threaded?
First, let’s look at the tasklet, because that’s not too different from what we’ve seen before.
-
@Tasklet(session = Tasklet.Session.CLONE)
-
private static class UserLookup implements Callable<String> {
-
super();
-
state_ = state;
-
stateName_ = stateName;
-
}
-
try {
-
StringBuilder sb = new StringBuilder();
-
.getView(“AllContactsByState”);
-
sb.append(stateName_ “: “);
-
sb.append(name);
-
sb.append(“, “);
-
}
-
return sb.substring(0, sb.length() – 2) “<br/>”;
-
t.printStackTrace();
-
return t.getMessage();
-
}
-
}
-
}
Because we want to wait for the outcome, in line 2 we implement Callable<String>, so the call() method should return a String. We’re not passing in a scoped variable, because we’re waiting for the result and then writing it to the scoped variable. But we do need to state name (for the output) and state abbreviation (for the lookup), so the constructor on lines 6 – 10 expects those variables and maps them to properties of the tasklet, so the call() method can use them. The code in the call() method itself is very straightforward and basically the same as the inner for loop from the background tasklet.
The code for calling it will need a little bit more explanation, but again is not rocket science.
-
HashMap<String, String> states = new HashMap<String, String>();
-
// Get first five states
-
states.put(doc.getItemValueString(“Key”), doc.getItemValueString(“Name”));
-
}
-
// Create a callable for each State
-
List<Future<String>> results = new ArrayList<Future<String>>();
-
UserLookup getUsers = new UserLookup(key, states.get(key));
-
results.add(Xots.getService().submit(getUsers));
-
}
-
// Now loop through the Xots tasks, and get the results
-
TreeSet<String> output = new TreeSet<String>();
-
for (Future<String> f : results) {
-
output.add(f.get());
-
}
-
ExtLibUtil.getViewScope().put(“MessageFromIterableXots”, output);
In lines 1 – 6 we iterate through the view of states and create a HashMap for the state abbreviation and the state name.
Then, because we want to wait for the result of the tasklet, in lines 9 – 13 we again create a List of Futures. Again, the datatype expected for the Future is String, because that’s what is being returned by the tasklet. We iterate through the HashMap we created, create a new instance of UserLookup for each state and add it to the List of Futures.
The XOTS service has an invokeAll() method which can take a Collection of Callables. At the moment that’s not working, so we just need to submit each in turn.
Next, in lines 16 – 19 we create a new TreeSet, iterate through the List of Futures and add the outcome of each tasklet, the list of names for that state. The reason for using a TreeSet here is that the tasklets will not complete in order, so e.g. American Samoa might complete before Arkansas. A TreeSet can order its contents, by default alphabetically (case sensitive). So even though the output from each tasklet may not be added in order, the resulting TreeSet is. Finally, on line 20, we add it to the viewScope variable.
Processing multiple threads against a single database and view may not provide significant performance benefits. But if those threads are processing multiple databases, for example, the benefits get bigger.
Currently XOTS is set to run 10 threads at any one time, but that can be configured.
