Memcached::Client is the central hub
During the loading of the
Memcached::Client::Request module, we insert a bunch of methods into the
Memcached::Client namespace that are really just curried functions that create instances of the various
When you make a request, things go like this (using
get as an example):
$client->get calls the anonymous subroutine that was returned when
M::C::Request::Get->generate (which, due to inheritance, is
M::C::Request->generate) was called.
The anonymous sub expects the
Memcached::Client object as its first parameter, and uses the remainder as arguments for its command. The command that was curried in when the subroutine was created is used to construct a hashref that will become the request object.
The last argument to the subroutine is examined. If it was something we can use as a callback (either a
CODE reference or an
AnyEvent::CondVar, it is stored, and we assume that somewhere else in the calling program there is a statement waiting on an
AnyEvent::CondVar---so we will not be obliged to do so ourselves in order for the request to get processed.
Otherwise we create the aforementioned
AnyEvent::CondVar and mark ourselves as needing to wait.
We then hand the rest of our arguments to the
process routine, which is supposed to verify the object's arguments and returns one or more
Request objects to be submitted to the appropriate server(s). If it does not return any objects, it is assumed that there was a problem with the submission, and an empty result is returned.
__submit routine in the
Memcached::Client module is handed the request objects to process.
__submit iterates through the objects, looking at whether they include a
key member. If they do, the key is processed to determine what server it should be directed at, checked for validity, and if it's OK, it is submitted to the appropriate server's queue using the connection's
If the object doesn't have a
key, it is assumed to be a broadcast message destined for all servers, and
__submit uses the object's
server factory to create subrequests for each server.
The connection object works its way through its queue (if there's nothing else in the queue when you add a new request, it will be handled immediately, but that's just an optimization) and comes to your request object.
It gets the name of the protocol function from your request object, and invokes that method on the protocol object, passing it a reference to itself and your request.
The protocol method constructs the command from the data members of the request object and submits it to the connection object.
When the response to the request has been recieved the protocol object decodes it and sends the result back to the request object using its
result method, and notifies the connection that it's done with the request by calling