On Thu, Mar 24, 2011 at 11:53 AM, Iris <[email protected]> wrote: > We tried to implement this wrapper with JavaBeanstalkClient. Our > initial implementation is to share use one connection for all the > requests.
That is a good approach. > Then we realize we will face a race condition with this > approach. For example, two requests come in for jobs. One is fetching > from tube A, one from tube B. If the two requests interlay with each > other, they may end up fetching from the same tube. JavaBeanstalkClient seems intended to be useful with multiple threads, so this problem is not unique to a beanstalkd proxy, but could happen with any client. Authors of Java client libraries: do you have a recommended solution? > Furthermore, we are concerned with performance. We don’t know how will > this scale with single connection. So we went with one connection per > thread option. You can't predict where performance problems will be. If it's simpler to have a single connection, do it that way first. Then, only if you have inadequate performance, measure to see where the bottlenecks are. If the connection is a bottleneck, only then should you bother to make multiple connections (and even in that case, having multiple connections might not help performance). 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.
