Lots of options. Need to think about this more. Maybe @marcosnils que help
us think this problem too.


On Mon, Jan 27, 2014 at 7:29 PM, Jungtaek Lim <notifications@github.com>wrote:

> In src/main/java/redis/clients/util/Pool.java:
>
> >      }
> >
> >      public T getResource() {
> > -	try {
> > -	    return internalPool.borrowObject();
> > -	} catch (Exception e) {
> > -	    throw new JedisConnectionException(
> > -		    "Could not get a resource from the pool", e);
> > +    synchronized (lock) {
>
> @xetorthio <https://github.com/xetorthio> One more approach is trying
> ReentrantReadWriteLock with read lock (get / return) and write lock (change
> pool).
>
> http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html
> Since write lock would be occurred when only master has changed, we can
> minimize running overhead for sync.
>
> --
> Reply to this email directly or view it on GitHub<https://github.com/xetorthio/jedis/pull/517/files#r9213090>
> .
>