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
>of a transaction requires setting the Runnable target on a thread to
>some application code that embodies the transaction.