-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Go-Redis concurrency model #2
Comments
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.) |
What changed between 1.2 and 1.3 that made it stateful? Is there more state than SELECT and AUTH ? |
… pool using channels for concurrency
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. |
Hi Ryan, Don't have the clicks right now (work) but will try to get to this over On Wed, 1 Aug 2012 11:09:53 -0700, Ryan Day wrote:
|
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! |
Does connection pooling get supported? |
It is not a high priority item but it is on the todo. |
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 On 09/24/2012 04:15 AM, Alex Luya wrote:
|
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.
The text was updated successfully, but these errors were encountered: