DATAREDIS-891 - Revise RedisConnection transaction/closure resource binding.

We now correctly consider the transactional state along with the requested bindings scope when binding RedisConnection for reuse.

Previously, enabling transaction support on RedisTemplate registered the connection unconditionally with TransactionSynchronizationManager expecting a TransactionManager to close/unbind the connection upon transaction cleanup. This behavior could easily lead to lingering connections when a transactional RedisTemplate was used outside of a managed transaction.

We now distinguish between closure-scope binding and transaction binding.

Closure-scoped bindings (RedisTemplate.execute(SessionCallback)) do not interfere with transactional resources if there's no transactionally bound RedisConnection.

Closure-scope however reuses a transactionally bound connection.

Transaction-scoped binding binds only a connection to the transaction if there's an active transaction. Without an ongoing transaction, RedisTemplate does no longer bind connections to TransactionSynchronizationManager.

Original Pull Request: #573

Author: mp911de

src/main/asciidoc/reference/redis-transactions.adoc

@@ -1,9 +1,9 @@
 [[tx]]
 = Redis Transactions
 
-Redis provides support for https://redis.io/topics/transactions[transactions] through the `multi`, `exec`, and `discard` commands. These operations are available on `RedisTemplate`. However, `RedisTemplate` is not guaranteed to run all the operations in the transaction with the same connection.
+Redis provides support for https://redis.io/topics/transactions[transactions] through the `multi`, `exec`, and `discard` commands.These operations are available on `RedisTemplate`.However, `RedisTemplate` is not guaranteed to run all the operations in the transaction with the same connection.
 
-Spring Data Redis provides the `SessionCallback` interface for use when multiple operations need to be performed with the same `connection`, such as when using Redis transactions. The following example uses the `multi` method:
+Spring Data Redis provides the `SessionCallback` interface for use when multiple operations need to be performed with the same `connection`, such as when using Redis transactions.The following example uses the `multi` method:
 
 [source,java]
 ----
@@ -20,14 +20,23 @@ List<Object> txResults = redisTemplate.execute(new SessionCallback<List<Object>>
 System.out.println("Number of items added to set: " + txResults.get(0));
 ----
 
-`RedisTemplate` uses its value, hash key, and hash value serializers to deserialize all results of `exec` before returning. There is an additional `exec` method that lets you pass a custom serializer for transaction results.
+`RedisTemplate` uses its value, hash key, and hash value serializers to deserialize all results of `exec` before returning.There is an additional `exec` method that lets you pass a custom serializer for transaction results.
 
 include::version-note.adoc[]
 
 [[tx.spring]]
 == @Transactional Support
 
-By default, transaction Support is disabled and has to be explicitly enabled for each `RedisTemplate` in use by setting `setEnableTransactionSupport(true)`. Doing so forces binding the current `RedisConnection` to the current `Thread` that is triggering `MULTI`. If the transaction finishes without errors, `EXEC` is called. Otherwise `DISCARD` is called. Once in `MULTI`, `RedisConnection` queues write operations. All `readonly` operations, such as `KEYS`, are piped to a fresh (non-thread-bound) `RedisConnection`.
+By default, `RedisTemplate` does not participate in managed Spring transactions.
+If you want `RedisTemplate` to make use of Redis transaction when using `@Transactional` or `TransactionTemplate`, you need to be explicitly enable transaction support for each `RedisTemplate` by setting `setEnableTransactionSupport(true)`.
+Enabling transaction support binds `RedisConnection` to the current transaction backed by a `ThreadLocal`.
+If the transaction finishes without errors, the Redis transaction gets commited with `EXEC`, otherwise rolled back with `DISCARD`.
+Redis transactions are batch-oriented.
+Commands issued during an ongoing transaction are queued and only applied when committing the transaction.
+
+Spring Data Redis distinguishes between read-only and write commands in an ongoing transaction.
+Read-only commands, such as `KEYS`, are piped to a fresh (non-thread-bound) `RedisConnection` to allow reads.
+Write commands are queued by `RedisTemplate` and applied upon commit.
 
 The following example shows how to configure transaction management:
 
@@ -65,7 +74,7 @@ public class RedisTxContextConfiguration {
 ----
 <1> Configures a Spring Context to enable https://docs.spring.io/spring/docs/{springVersion}/spring-framework-reference/data-access.html#transaction-declarative[declarative transaction management].
 <2> Configures `RedisTemplate` to participate in transactions by binding connections to the current thread.
-<3> Transaction management requires a `PlatformTransactionManager`. Spring Data Redis does not ship with a `PlatformTransactionManager` implementation. Assuming your application uses JDBC, Spring Data Redis can participate in transactions by using existing transaction managers.
+<3> Transaction management requires a `PlatformTransactionManager`.Spring Data Redis does not ship with a `PlatformTransactionManager` implementation.Assuming your application uses JDBC, Spring Data Redis can participate in transactions by using existing transaction managers.
 ====
 
 The following examples each demonstrate a usage constraint: