如何改进这个连接池设计？
首先，我正在开发自己的 DBCP（数据库连接池）实现，因此，
我不会接受任何使用 c3p0 等第三方 DBCP 的建议。
我正在使用生产者-消费者设计模型作为我的 DBCP 的主要设计模板。
PRODUCER | CONSUMER
Pn, ... P3, P2, P1 >> << C1, C2, C3, ... Cn
对于生产者和消费者，我使用 LinkedList 队列。
PRODUCER 队列
它将由最大数量的 SQLConnectionWrapper 实例填充。我已采取措施确保连接在队列中是唯一的。在 .close() 上，连接将
- 首先删除 C 队列中的第一个元素（如果有），
- 否则将排队到 P 队列中。
我使用管家线程来删除队列中陈旧/过期的连接，并生成新连接以保持配置的最小连接数。
CONSUMER Queue
它将由 FutureTask 实例填充。使用我的 DBCP 的应用程序将调用
Connection conn = dbcp.getConnection(long timeout);
它，
- 首先创建一个 Consumer FutureTask，
- 删除 P 队列中的第一个元素（如果有），
- 否则将其排队到 C 队列中，
- 阻塞 .get(timeout) 直到它被“馈送”由制作人或暂停，以先到者为准。
我的问题
这个设计可以进一步改进吗？有什么明显的弱点吗？
我的首要任务是并发使用环境中的稳定性。我从当前的测试中了解到，由于涉及两个队列，因此需要双方同步。
现在，我正在探索这样的想法：
- 将2个队列减少为1个双端队列（尽管我很难思考如何让P端消灭C端）
- 创建一个同步消灭器线程，消除对生产者和消费者的需要来互相检查。
First off, I am developing my own implementation of DBCP (database connection pooling), as such,
I won't accept any suggestions to use 3rd party DBCP like c3p0.
I'm using the producer-consumer design model as the main design template for my DBCP.
PRODUCER | CONSUMER
Pn, ... P3, P2, P1 >> << C1, C2, C3, ... Cn
For both producer and consumer, I use LinkedList queue.
PRODUCER Queue
It would be populated by a maximum number of SQLConnectionWrapper instances. I have taken steps to ensure the connections are unique in the queue. Upon .close(), the connection would,
- first, remove the first element in the C-queue, if any,
- else, queue into the P-Queue.
I employ a house-keeper thread to remove stale/expired connections in the queue, and to spawn new connections to keep the minimum number of connections as configured.
CONSUMER Queue
It would be populated by FutureTask instances. Apps using my DBCP would call
Connection conn = dbcp.getConnection(long timeout);
which would,
- first create a Consumer FutureTask,
- remove the first element in the P-queue, if any,
- else, queue into the C-queue,
- blocking on .get(timeout) until it is 'fed' by a Producer or time-out, which ever comes first.
My Question
Can this design can be further improved? Any notable weaknesses?
My priority is stability in a concurrent usage environment. I've learned from my current testing that it needs synchronization on both sides since 2 queues are involved.
Right now, I am exploring ideas like :
- reduce the 2 queues into 1 deque (though I have trouble thinking on how to get the P-side to annihilate the C-side)
- create a synchronized annihilator thread, removing the need for PRODUCER and CONSUMER to check each other.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
既然你已经说过你不会接受任何第三方矿池的建议。我想你的意思是任何第三方连接池。
你可以看到类似apache commons连接池的东西，它为任何物体。因此，虽然我没有冒犯的意思，也不想让你泄气，但我认为你正在尝试重新发明轮子。
话虽如此，上面的链接给出了通用池的非常高层次的设计。检查如何使用游泳池，您将对正在发生的事情有一个清晰的了解，并且也将帮助您进行设计。
Since you have said you will not accept any third party pool suggestions. I guess u mean any third party connection pool.
What you can look is something like apache commons connection pool, that provides pooling facilities for any object. So while i mean no offense and dont want to discourage you, i think you are trying to re-invent the wheel.
Having said that, the link above gives a very high level design of the generic pool. Check how to use the pool and you will get a fair idea as to what is going on and will help you with your design too.