Having spent a fair amount of time implementing OLTP system, I do support the "one transaction, one thread" design. Every design make tradeoffs and this one has proved to be a sweet spot in terms of balancing complexity and performance (e.g. maximizing throughput).


Thompson, Bryan B. wrote:
> I am wondering about the relationship between transactions, threads,
> and locking for 2PL. If the API assumes that the thread is the
> context in which the locks apply, then the lock object (which
> contains some metadata about the lock) can be hidden (for the most
> part) from the application and the method for releasing a lock can
> simply use the current thread to determine which lock should be
> released. A lock which is not granted immediately causes the thread
> in which the lock request was made to block. This makes all kinds of
> good sense and is how the java.concurrent.util APIs are laid out.
> However this assumes that the notion of a transaction is equivalent
> to a thread, that there can not be more than one transaction per
> thread, and that the transaction can be inferred from the thread.
> This also suggests that a transaction factory is basically a thread
> pool (which gives us a means to limit concurrency) and that execution
> of a transaction requires setting the Runnable target on a thread to
> some application code that embodies the transaction.
> Thoughts?