Task-based vs actor-based thread usage

December 16, 2007

Last week I was reading “Concurrent Programming in Java” from Doug Lea in the train to my work. One of the topics I was reading was chapter 4 “Creating threads” and a distinction was made between 2 different approaches for using threads:

  1. task-based: when a task needs to be executed asynchronously on a different thread. An example of this is the execution of a batch process started by a Servlet thread when a user pressed a button. After the task is executed, it can be discarded. The Executor was made for task based problems although it lacks some functionality for blocking when a task can’t be processed.
  2. actor-based: when a thread runs as an automonous process (the actor) and is able to react on events from the environment. An example of an acter based design is a thread that runs a server socket. When a client request is accepted, the server socket processes the request and waits for the next request.

It is possible to combine the actor and task-based styles, e.g. as soon as a socket-request from a client is accepted, the task of processing this request could be executed asynchronously on a different thread (task based) using an Executor to keep the serversocket (actor based) available to other clients.


Executing long running task from UI

December 15, 2007

A colleague asked me how one could prevent the execution a long running task on some UI thread (e.g. the thread of a Servlet container or the Swing event dispatching thread) and also how one could prevent the concurrent execution of that same task. So I send him an email containing a small example and decided to place it on my blog to help others struggling with the same issue.

The long running task

The FooService is the service with the long running method ‘foo’.

interface FooService{
        void foo();

There is no need to add threading logic to the FooService implementation. It can focus purely on the realization of the business process by implementing the business logic. The code should not be infected with concurrency control logic, because it makes testing very hard, and makes code also hard to understand, reuse or change. So this is one of the first potential refactoring I often see in code. I’ll post more about this in ‘Java Concurrency Top 10’.

The execution-service

The FooExecutionService is responsible for executing the FooService and preventing concurrent execution (if the correctly configured executor instance is injected). Personally I prefer to inject the executor instead creating one inside the FooExecutionService, because it makes it hard to test and change/configure.

class FooExecutionService{

        private final FooService fooService;
        private final Executor executor;

	public FooExecutorService(FooService fooService, Executor executor){
		this.fooService = fooService;
		this.executor = executor;

	 * Starts executing the FooService. This call is asynchronous, so
         * won't block.
	 * @throws RejectedExecutionException if the execution 
	 *         of foo is not accepted (concurrent/shutdown).
	public void start(){
                executor.execute(new Task());

        class Task implements Runnable{
                void run(){
                        catch(Exception ex){
                                log.error("failed to ...", ex);

The FooExecutionService could be improved in different ways: it could provide information when a task already is executing. This could be realized by placing a dummy task in the executor and check if the task is rejected. A different solution would be to let the Task publish some information about the status of the current execution. If the task is very long running, and you want to be able to stop the task, you could shutdown the executor by calling the shutdownNow method. This interrupts the worker-threads and if you periodically check the interrupt status of the executing thread while doing to long running call, you can end the execution.

Some Spring configuration

The Executor is injected from the outside by some Spring configuration, i.e.:

<bean id=""fooService" class="FooServiceImpl"/>

<bean id="fooExecutionService" class="FooExecutionService">
        <constructor-arg 	index="0" 
        <constructor-arg 	index="1">
            	<bean 	class="java.util.concurrent.ThreadPoolExecutor"
			<!-- minimal poolsize (only 1 thread) -->
                	<constructor-arg 	index="0"
                	<!-- maximum poolsize (only 1 thread)-->
                	<constructor-arg 	index="1"
                	<!-- the timeout (we don't need it) -->
                	<constructor-arg 	index="2"
                	<!-- the timeunit that belongs to the timeout argument (we don't need it) -->
                	<constructor-arg index="3">
                    		<bean 	id="java.util.concurrent.TimeUnit.SECONDS"
                	<!-- the workqueue where unprocessed tasks get stored -->
                	<constructor-arg index="4">
                    		<!-- we don't want any unprocessed work: a worker needs to be available,
                 		or the task gets rejected. -->
                    		<bean class="java.util.concurrent.SynchronousQueue"/>

If there are multiple long running methods, it would be an idea to extract the creational logic of the executor to a factory method.

The UI-controller

And the FooExecutionService can be hooked up to some controller like this:

class StartFooController extends SomeController{
        final FooExecutionService fooExecutionService;
	StartFooController(FooExecutionService fooExecutionService){
		this.fooExecutionService = fooExecuctionService;
        String handleRequest(Request request, Response response){
                        return "success";
                }catch(RejectedExecutionException ex){
                        return "alreadyrunningorshuttingdownview";

Prevention of concurrent execution of different tasks

If you want to prevent concurrent execution of different long running methods, you could create a single execution-service for all methods, and share the same executor between the execution of the different tasks: