---
This constructor type is available on the ```Jedis``` class and so I added it to ```JedisPool``` for consistency.
Conflicts:
src/main/java/redis/clients/jedis/JedisPool.java
---
This corrects a [findbugs](http://findbugs.sourceforge.net/) warning about how iteration over a key set followed by a call to ```get``` is less efficient than iterating over an entry set.
---
We would like to add the ability to specify the database number on the pool config. We have a number of integration/functional tests in different projects using redis and would like to keep them separate. Setting up a number of redis server instances on different ports would become unwieldy.
The changes add the ability to specify the database number for jedis pools with associated test. I did not add the ability to create a raw jedis connection with a database number because the current implementation of pool creates the jedis object first, then if a password exists it calls the auth command. However, if a password is required, then the select command on the jedis create would fail. I also did not change the shard constructor of jedis to use a database number (which actually does have the constructor of jedis call the auth command).
I could clean up the implementation to always have the jedis constructor call auth if a password exists, then select the database if it is non-zero, and changing sharding info to contain a database config value. Let me know if you want me to make these bigger changes.
---
The subscribe and psubscribe operations call setTimeoutInfinite() since they never return on their own. If the Redis server goes away without closing the connection, the connection can hang indefinitely. Turning on keep-alive will allow the connection to eventually timeout and attempt reconnection.
Note that keepalive must also be enabled on your server, see the Linux HOWTOs on how to do this.
