有个疑问如果不release，那我有多个请求的时候，假如有10个session都在处理请求，第11请求来的时候，怎么知道哪个session可用？我理解的话，这个时候session池已经用光了，又没有归还动作。
假如用户自己维护的session列表满了，需要用户自己做处理，比如进入等待队列，等上一个释放，或者直接报错。java client里面用的对象池是有等待机制的，默认是不等待，只是没有开放给用户配置，你也自己增加这个配置。
我大概了解了，你的意思是用户自己维护一个类似executors 的池子来管理session，单纯nebula的pool不使用release，是没法做session连接管理的，是这个意思吗？还有个疑问，还需要用户管理session可用状态把？
java-client现在的默认行为是，连接用完了，用户去get session是直接报错的，假如你想阻塞的话，需要把阻塞时间开放出来，就看你选择哪种行为。
我得意思是即使是阻塞，那也需要等待session归还到池子里面，如果不用release 归还session，那么要怎么触发归还的逻辑，超时触发？感觉性能影响很大。这是我的想法，可能和你的理解有差异。
. 我得意思是即使是阻塞，那也需要等待session归还到池子里面，如果不用release 归还session
这是肯定的呀，你有11个线程一直要用，但是就10个session，那就是你设置的session数不合理，要用等待的情况，肯定是你业务就是用完会释放的时候，才可以这样用。
1 个赞
那实际上为了高性能，不使用release归还session，用户最好自己维护一个session池，池子和pool一样大，并且管理好session的可用性，我这样理解对吗？
那实际上为了高性能，不使用release归还session，用户最好自己维护一个session池
假如你的业务都是操作同个space，用户也是同一个，那么为了减少中间多余的io交互，你可以自己再增加个session组，自己管理。假如你的业务使用常见会针对不同用户，不同space，那么就没有必要了。
并且管理好session的可用性，我这样理解对吗
session 的可用性指什么，假如你是指连接可靠，这个不需要你包装，Java client已经保证了，你只需要保证你的session用的是什么用户和space可以。
那我理解差不多和你是一致的，多个space也可以根据实际情况维护一个map session组。
session 的可用性指什么
举个例子，你前面有提到session有的时候会不可用，需要释放，重新getSession。如果我自己维护session组，那我理解这里是需要用户手动处理的。而如果每次调用后，使用release是不会有个这个情况的，就算session不可用也会释放掉。
举个例子，你前面有提到session有的时候会不可用，需要释放，重新getSession，那我理解这里是需要用户手动处理的
这个是旧版本的，服务端还不支持重连的时候，当你池里初始化多个服务的时候，有服务挂了，这个时候需要重新拿session才能正常使用。新版本的支持了，这个池和服务端就会保证了，但是当所有服务异常还没恢复这段时间，用的拿到的session肯定是不能用的，当所有服务恢复后，那么再次通过session执行query的时候，session就会拿可用的连接和服务正常通信。
那我了解了，用新的版本，考虑性能，自己就只需要维护一个session池就好了，感谢。
这个session池如何实现啊，我这边有点不清楚，难道就是个数组或者集合？
升级新版本把，官方有实现
哪有这么容易，说升就升 
，我假如只创建一个session，如果这个session出问题了，异常了，咋办