Confusing unit-of-work with threads

While I agree with this point theorically, I don't think multi threads unit of works can be applied practically (in most applications).

If you take transaction management, for example, it is clear that the transaction life must be bound to your unit of work. Problem is, in application servers, JTA transactions (and associated resources as JDBC connections obtained through JNDI lookup) are bound to a particular thread. Same goes for caller information and other useful, infrastructure provided data.

If you were to implement a multi thread unit of work, you'd have to abandon those low level features. It simply seems too much pain for me. I prefer using a logical unit of work (in the use case sense) that spans several technical units of work (in the ORM/tx sense of the term) that can be distributed amongst many thread. Mechanisms as workflows, JMS asynchronism, sync points, ... exist to support this way of programming, and you still can use all the features provided by your application server.

JTA is particularly insidious in this regard (binding work to the current thread). Actually, that seems common in most transactional systems. I even think that's ok as long as you can strip the info off the thread at some point and move it to a different thread.

When I was at MetaMatrix, we used the Atomikos transaction manager and we were able to move transactions between threads (and include sub-transactions on different VMs). But it certainly wasn't pretty and didn't seem to be the way people normally used it.

Indeed, sharing connections and transactions between threads is unusual and unpractical. Also, the transaction schemantics of JTA and Spring - notably, the propagation levels - have clear behavior when it comes to delimiting the association of "unit-of-work" objects with the threads.

There are two approaches I have taken to share context between threads. Both required a pool of threads to share a ThreadGroup.
1) Create a ThreadGroupLocal. This holds a value/values for each ThreadGroup shared between threads in that group.
2) Create a custom ThreadGroup which holds a thread safe Map of values.

Where you have something which is single threaded I associate a single thread pool and a cached (variable sized) pool with the thread group. Single threaded processing requires adding a task the first pool and any which isn't single threaded is added to the second pool.

This is the cut down version. You add sub-tasks to either the single pool or the multi threaded pool. The single threaded pool can kick off any number of tasks concurrently and then collect the results with the Future.get() method. Multi-threaded tasks can add sub-task which must run in the same threaded to the single pool.
This structure is used to run a large number of unrelated tasks at once. (Although the single threaded portions have to wait for each other)

public class MyThreadGroup extends ThreadGroup{
    public MyThreadGroup(String name) {
        super(name);
    }

    private final ScheduledExecutorService executorService = Executors.newSingleThreadScheduledExecutor(new MyThreadFactory());
    private final ExecutorService multiExecutorService = Executors.newCachedThreadPool(new MyThreadFactory());
    private final Map<String, Object> values = new ConcurrentHashMap<String, Object>();

    public static <T> Future<T> submitSingle(Callable<T> callable) {
        // add code to check in is not in the single threaded executor already.
        return getMyThreadGroup().executorService.submit(callable);
    }

    public static <T> Future<T> submit(Callable<T> callable) {
        return getMyThreadGroup().multiExecutorService.submit(callable);
    }

    public static Object getValue(String key) {
        return getMyThreadGroup().values.get(key);
    }

    public static Object setValue(String key, Object value) {
        return getMyThreadGroup().values.put(key, value);
    }

    private static MyThreadGroup getMyThreadGroup() {
        return (MyThreadGroup) Thread.currentThread().getThreadGroup();
    }

    class MyThreadFactory implements ThreadFactory {
        public Thread newThread(Runnable r) {
            return new Thread(MyThreadGroup.this, r, getName());
        }
    }
}

</t></t></t></t></t></t>

In Java EE 5, this disparity has been addressed with the new TransactionSynchronizationRegistry interface. In particular, take a look at the putResource(Object,Object) and getResource(Object) methods.

-Patrick

--
Patrick Linskey
bea.com

JTA is particularly insidious in this regard (binding work to the current thread).

Probably what you are missing is the idea of fluid variables (called special variables in Common Lisp).