Does the Spring transaction manager bind a connection to a thread?

Question

I found the following thread: How exactly JdbcTemplate with TransactionManager works together?

The first sentence of that:

As far as I understood DataSourceTransactionManager binds a JDBC connection from the specified DataSource to the current thread, allowing for one thread-bound Connection per DataSource. If it's a pool of connections, it will take one of the available connections.

... is exactly what I want to know.

When using a transaction manager, do you end up with each thread having it's own single connection? Also, how long does that connection live? Does the same thread use the same connection throughout a single request, or is there something else going on? I'm just trying to understand what exactly Spring is doing underneath when you have a transaction manager and when you don't (regardless of whether or not you actually have a transaction).

Dusk

Answer 1

When using a transaction manager, do you end up with each thread having it's own single connection? Also, how long does that connection live?

The connection is generally obtained from a connection pool. The connection is borrowed from the pool when the transaction manager starts the transaction, and then returned to the pool when the transaction finishes. During that time, the connection is bound to the thread.

Does the same thread use the same connection throughout a single request

It uses the same connection for the duration of the transaction. The request itself is irrelevant.

regardless of whether or not you actually have a transaction

You always have a transaction, whether you do it explicitly or not. If you don't configure one explicitly, then the JDBC driver and database will start and finish one for as long as it takes to perform the single operation. Spring's transaction management (or any other framework's transaction management) lets you extend the lifetime of that transaction across multiple operations. Doing so requires exclusive use of the connection for the duration of the transaction.

Apples

Thank you for your response. It helps me understand a little more of what's going on. I understand how the transaction management allows the transaction to extend for multiple operations. However, in my case, I have @Transactional(propagation=Propagation.SUPPORTS) on each of my DAO methods, meaning each call will use it's own independent transaction. After the manager gets an initial connection from the pool does it then bind that connection to the current thread, and then retrieve it from there for the life of the thread, instead of going back to the pool to get a connection? – Dusk

"each call will use it's own independent transaction" - this is not true. Your DAO will "inherit" any existing transaction that's already bound to the thread. it will not start a new one unless there's none already bound. – Apples

I guess the way I'm defining "transaction" isn't totally correct. The way I have understood a transaction is when you have a single DB operation (which could have any number of updates, inserts, etc.) It all happens or none of it happens. The way the DAO is set up, each method will operate on the DB independent of the other methods. If one method fails, it won't affect what operations were performed by other methods before or after the failed one. So, what exactly is a "transaction" then? I was thinking each method would be creating it's own new transaction, but apparently that's not the case? – Dusk

Do you guys know what's the lifetime of a connection obtained by the DataSourceTransactionManager? – Dobson

when is the connection closed? when jdbctemplate method finishes, or when the actual transaction finishes? – Wrestle