分享一个帖
JoyceLikeRose opened this issue · comments
感谢他的点论,简单说几句吧.
1: 对于他所说的BeeCP存在不安全的问题
这,这,听起来有点危言耸听(Brett Wooldridge先生说话太幽默了),他所指的不安全问题是指连接在使用完毕后,某些属性需要重置一下,避免带入到到下一次使用.BeeCP池代码中有相应处理,并且有对应的测试案例,项目在打包的前时候会执行,如果有问题版本包是无法打成的。或者用光连接基准对真实的数据库检验(DefaultAuto=false),如果数据写入数据库了,表示连接池存在问题.在BeeCP的一些比较老的版本中确实这个问题;当然拉,也许还存在在其他问题,欢迎网友发现,我们及时纠正.个人觉得对于问题的描述，用测试案例或异常堆栈等有力证据性说明更清晰,否则只是一个空洞的结论。
2: 对于他说的BeeCP是从光连接池中Copy而来。
这个说法是站不住脚的,有兴趣的同学可以对比两套代码,代码差异非常大,几乎没有可比性。
但是由于都是连接池产品,那么在一些非关键性地方,可能存在一些相似性（比如方法名类名相同)
对于连接池而言,有两个关键点:1:取连接 2:归还连接,如果非要要对比差异,可以从这两个方面入手。存储结构方面,BeeCP:Semaphore+连接数组+ThreadLocal+ConcurrentLinkedQueue+TransferPoliy+PSCache;
光:ThreadLocal+FastList+CopyOnWriteArrayList+SynchronousQueue+ConcurrentBag.
存储结构的差异性,那么处理过程差别大的去了.
实事求是的说:个人曾经阅读过光连接的代码,不少地方看起来比较生涩难懂(个人水平不够)最终放弃.
BeeCP核心关键逻辑是在反复阅读SynchronousQueue获得的灵感,另生成jdbc的代理方式灵感源自阿里的一篇文章（感谢阿里），大约只有有几个小点确实是参考光(比如支持驱动Datasource)思路点. 个人曾在Maven上提交过多个版本，为啥要这么干呢？因为一直在努力尝试各种代码改变带来的性能的提升。如果要Copy的话，一步到位岂不是更好？
3: 对于他说的BeeCP和Druid以及与**政府的猜测
一个好奇者的提问罢了,同时说明Brett Wooldridge先生很受欢迎,用户喜欢找他交流
Druid和BeeCP均来自**，二者之间不存在关联性，前者是阿里公司产品，后者为个人作品，和政府也没有半点关系。
BeeCP包以cn.命名有两点原因，1：短包名 2：表明来自**
BeeCP命名原因：蜜蜂是一种勤劳的小昆虫，是人类的好朋友，但是由于环境的改变导致数量下降，希望社会重视这个事情。
4：为什么要开发BeeCP
网上光连池追捧的广告,几乎是铺天盖地,很多人说它是史上最快的池,甚至还有人说它可与光速媲美(太吓人了,不知道是怎么对比出来的^-^),又或是某个池的几百倍性能,又或是性能碾压某某池等等,感觉光连接池快成一个无法超越的，顶级膜拜的神话了. N年前个人有个大胆的想法:打破这个神话,开发一个性能更高的池. 连接池领域中没有最快,只有更快. 超越并不是要排斥光连接池,光连接池本身就是一个很大的进步,为Java世界做出很大的贡献,应该被赞扬与肯定!
欢迎挑战者,科技的进步也许就是这样一次又一次挑战而来的. 为正在路上的挑战着鼓掌!也为曾经的挑战者鼓掌!