ERR MULTI calls can not be nested about lettuce HOT 8 CLOSED

Thank you for your report. lettuce connections are in general threadsafe but not stateless. Issuing a MULTI command will turn lettuce connections into a transactional state. All commands issued after a MULTI command are then within the transaction scope until either EXEC or DISCARD are issued.

The connection state means also, that calling MULTI twice will initiate the transaction twice and then try again to start the transaction. The mentioned exception ERR MULTI calls can not be nested is issued by Redis. I assume, that your test case can change the connection in a state, where the first transaction state might be lost, but I have to check this first.

Can you tell me about your expectation in this case?

from lettuce.

Until now, no further action, but it might be worth having a sketch for a transactional buffer utility.

from lettuce.

diffrent business data stored in redis with diffrent dbIndex ,
I will concurrently send command ( multi ; select x; set y ; exec;)
then I get this error.

from lettuce.

You will need two connections, every connection can be at one database at a time. All commands are issued immediately to Redis, even those preceded by a MULTI commands. This means commands are not buffered until you fire EXEC.

from lettuce.

thanks , I will try it .

from lettuce.

@mp911de Apologies for resurrecting such an old thread, but I'm having a little conceptual trouble with this. I just hit this error, and don't quite understand something you said upthread:

lettuce connections are in general threadsafe but not stateless

What does this mean? Generally, statefulness implies non-threadsafe. Is it the case that a MULTI call requires thread synchronization? That is, if we use MULTI, must we guarantee that only that thread is actively using the connection?

from lettuce.

Statefulness and thread-safety are not mutually exclusive. Lettuce connections are initialized and handed over to the application. The initial state is (looking at transactions), that the connection is not in a transactional state. This state can be changed concurrently but requires external synchronization. Without synchronization, things like interleaving or other race conditions may happen.

That is, if we use MULTI, must we guarantee that only that thread is actively using the connection?

In short: Yes, only a single thread is allowed to actively use the connection.

The longer version is:

Without changing the state, a single connection is thread-safe and can be shared across multiple threads. If you need to change the state (run transactions), then you need to introduce some sort of isolation. That can be synchronization (thread 1 runs its transaction and awaits its completion, then thread 2 runs its transaction and so on) or allocating connections per thread (invocation) by e.g. using connection pooling.

from lettuce.

Thanks for the sensible explanation. I see now what you mean by "threadsafe but stateful". Individual commands are sent in a threadsafe manner, but application logic (transactions) must be synchronized at a higher level.

from lettuce.