On Mon, Aug 17, 2009 at 6:43 AM, Andrew Gomilko<[email protected]> wrote: > Now, we have clear protocol which states that all client/server > communication is in serial mode, > req->resp, req->rest and so on. In this model, one client should be > used by one thread. > > But adding this feature might add some ambiguity if some methods might > be called simultaneously > (e.g. you can call cancelReserve() only when you are in reserve() state).
It seems like the issues you raise have more to do with programming a client with multiple concurrent threads sharing a single connection to beanstalkd. Such a client might have race conditions or other ambiguities, but that is outside the scope of the beanstalk protocol. In the protocol, there would be no "cancelReserve" command. I haven't speculated about how this might be exposed in client libraries, but I'd strongly recommend they *not* provide a cancelReserve method, but instead send pipelined commands as usual. The command stream is serial, and there would be no semantic difference with this feature. The only difference is that reserve-with-timeout might, at its discretion, time out earlier than normal. kr --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en -~----------~----~----~----~------~----~------~--~---
