Use before assignment of asyncDedicatedConnection in LettuceConnection

[oldium]

I found issue while reading how Lettuce integration works in this method:

spring-data-redis/src/main/java/org/springframework/data/redis/connection/lettuce/LettuceConnection.java

Lines 966 to 975 in 777f079

	protected StatefulConnection<byte[], byte[]> doGetAsyncDedicatedConnection() {
	StatefulConnection<byte[], byte[]> connection = getConnectionProvider().getConnection(StatefulConnection.class);
	if (customizedDatabaseIndex()) {
	potentiallySelectDatabase(this.dbIndex);
	}
	return connection;
	}

The method creates a new connection, which is stored by the caller into a asyncDedicatedConnection attribute:

spring-data-redis/src/main/java/org/springframework/data/redis/connection/lettuce/LettuceConnection.java

Lines 1026 to 1033 in 777f079

	private StatefulConnection<byte[], byte[]> getOrCreateDedicatedConnection() {
	if (this.asyncDedicatedConnection == null) {
	this.asyncDedicatedConnection = doGetAsyncDedicatedConnection();
	}
	return this.asyncDedicatedConnection;
	}

But it looks like the asyncDedicatedConnection is used before assignment in potentiallySelectDatabase() called by doGetAsyncDedicatedConnection():

spring-data-redis/src/main/java/org/springframework/data/redis/connection/lettuce/LettuceConnection.java

Lines 1068 to 1073 in 777f079

	private void potentiallySelectDatabase(int dbIndex) {
	if (asyncDedicatedConnection instanceof StatefulRedisConnection<byte[], byte[]> statefulConnection) {
	statefulConnection.sync().select(dbIndex);
	}
	}

[mp911de]

This is a bug, good catch. We need to apply the database selection clearly on the newly created connection. Do you want to submit a pull request?

[oldium]

Please do it if you have time :-)

[oldium]

Turns out the logic is broken here. select() refuses to use shared connection, so it executes the select command on a dedicated connection. This means that the potentiallySelectDatabase() call is superfluous in doGetAsyncDedicatedConnection, because the database change will be executed in select call anyway.

I am not able to tell the difference between connection.sync().select() (used in potentiallySelectDatabase method) and invokeStatus().just(..., CommandType.SELECT, ...) (used in select method), though.

[oldium]

Please check oldium@e47545a for possible fix. As I said, I am not sure whether the invokeStatus() (it uses RedisClusterAsyncCommands::dispatch, which is actually BaseRedisAsyncCommands::dispatch) is comparable/equivalent to connection.sync().select() call.

[oldium]

@christophstrobl I do not think the fix is correct and the change to the test proves it. The SELECT Redis command is executed twice, first time in RedisCommands.select() call and second time in the BaseRedisAsyncCommands.dispatch(SELECT) call. Please see my former comments.

[christophstrobl]

thanks for the heads up - true - working on it.

[mp911de]

You're right, we're setting now the database index twice. We had initially a different understanding. By removing the database index customization check and db selection in doGetAsyncDedicatedConnection(…) we can address the issue.