Are async Transactions still completed sequentially?

[pvlov]

The Documentation of Redis guarantees that the commands inside of a transaction are issued sequentially see docs. Is this also guaranteed with lettuce?

To be more specific, lets say we have the following code-snippet:

        RedisAsyncCommands<String, String> api = redisConnection.async();

        api.multi();
        api.set("testKey", "testValue");
        api.get("testKey");
        api.set("testKey", "someOtherTestValue");
        var future = api.exec();

Will it be guaranteed that the get()-call will only be issued upon the Completion of the set()-call before it? Or do you need to compose the RedisFutures to make sure that they will be issued sequentially?

[mp911de]

Commands are sent in-order. The important bit is to not share the same redisConnection across threads to avoid shared mutable state. Other than that, this is the preferred pattern as you're not awaiting completion and benefitting from pipelining.

[pvlov]

What would happen if you would share the StatefulRedisConnection among threads? I imagine it could cause the multi-blocks to fail since the multi blocks of different threads could "mix", is that the correct guess here? Is there a way to share a StatefulRedisConnection without the need to give every thread their own connection (as the connection are quite expensive)?

[mp911de]

Then talking async, do not share across threads requires a bit more clarification. In a thread-per-request application design, sharing a connection across threads can lead to visibility and shared mutability issues as the multi state and command outputs are held within the connection. Any concurrent access would make different state assumptions regarding the connection state and ultimately fail.

If you ensure isolation between request sequences (that is, that a transaction is only operated by one series of invocations that belong together) you could invoke commands asynchronously from different threads. However, if a second process starts using the same connection while the previous transaction isn't cleaned up, then you end up with shared mutable state issues again.

Let me know whether this helps.

[pvlov]

Thanks for the detailed response!

I have solved my problem by now. For the sake of completeness I'll detail how I solved it here:
My main problem arose from sharing a stateful connection and using transactions, this of course leads to the problem of the different threads assuming a "clean" state of the connection. This led to exceptions due to exec()-calls without a multi()-call, probably from a race-condition. Funnily enough, the documentation already mentions this kind of problem with async and transactions.

My solution was sharing the RedisClient among the thread which according to the documentation is the memory-expensive part. Each Thread would then have their own connection based off of the RedisClient and would then close the connection once it is done with whatever it was meant to do. When using spring, registering the RedisClient as a Bean and specifying the destroyMethod of it as "close" is a good way to make sure it gets cleaned up properly once the RedisClient is not needed in the application context. This solution works well for my case, as the threads are rather short-lived, so this might not be a viable solution for highly concurrent code.

Another thing im wondering however, is what exactly is meant with "[...]serializing transactions[...]" in the documentation. Is this referring to custom commands?

[mp911de]

serializing transactions

Refers to synchronization so that transactions on a single connection happen serially and not parallel. That can be achieved by a lock or a synchronized block as naive examples.