Go-Redis concurrency model

[hoisie]

Right now Go-Redis doesn't support concurrent access to a client. I.E if a SynchClient is shared among different goroutines, it is common for conflicts to occur.

For instance, if two goroutines send a command on a single Synchclient at the same time, and both try to read the results, the clients end up reading each other's data and causing read conflicts.

I think it would be cool if Go-Redis handles concurrency for you. It would require maintaining a connection pool, but it would make the library easier to use.

[alphazero]

Hoise,

(V sorry for the very late reply. Got side tracked there ..)

Its correct that Synch clients are not safe for concurrent use. I was planning to follow the pattern set in JRedis and provide service clients, but Redis 1.3.n's is firmly established as a stateful protocol and connection pooling would not be possible. (I have no say in that, so that's that.)

That said, pipelines (Asynch) are perfectly capable of handling concurrent use. Just invoke the get method on the future result and you effectively have synchronous semantics and concurrent use of a connection.

(I'll keep this issue open as needs to be revisited.)

[hoisie]

What changed between 1.2 and 1.3 that made it stateful? Is there more state than SELECT and AUTH ?

[rday]

I botched the commits here, but the general idea is to have pooled connections, and use channels to decide which connection is available for the ServiceRequest. I've tested this using AB and haven't run into data errors, but it hasn't been used in a real heavy production scenario yet.

[alphazero]

Hi Ryan,

Don't have the clicks right now (work) but will try to get to this over
the weekend.
Thanks.

On Wed, 1 Aug 2012 11:09:53 -0700, Ryan Day wrote:

I botched the commits here, but the general idea is to have pooled
connections, and use channels to decide which connection is available
for the ServiceRequest. I've tested this using AB and haven't run
into
data errors, but it hasn't been used in a real heavy production
scenario yet.

---

Reply to this email directly or view it on GitHub:
#2 (comment)

[rday]

No problem. The pull is titled AsyncClient Interface because it includes some additions I made for that interface, as well as a "go fmt", which makes it look like more than it is. The real meat is 290 through 298, where I use a channel to communicate the next available connection for handling a service request. I'd be very interested in your thoughts on that method. Thanks!

[AlexLuya]

Does connection pooling get supported?

[alphazero]

It is not a high priority item but it is on the todo.

[rday]

My fork has pooling in it, although it isn't yet supported in master.

You can put an abstract pool on top of GoRedis though, check out
https://gist.github.com/3504674 and https://gist.github.com/3504712 for
an example.

On 09/24/2012 04:15 AM, Alex Luya wrote:

Does connection pooling get supported?

—
Reply to this email directly or view it on GitHub
#2 (comment).