Во-первых, я разрабатываю собственную реализацию DBCP (пул соединений с базой данных), как таковую,
Я не приму никаких предложений по использованию сторонних DBCP, таких как c3p0.
Я использую модель дизайна "производитель-потребитель" в качестве основного шаблона дизайна для моей DBCP.
PRODUCER | CONSUMER
Pn, ... P3, P2, P1 >> << C1, C2, C3, ... Cn
Как для производителя, так и для потребителя я использую очередь LinkedList.
Очередь производителя
Заполнено максимальное количество экземпляров SQLConnectionWrapper.Я предпринял шаги для обеспечения уникальности соединений в очереди.После .close () соединение,
- сначала, удалит первый элемент в C-очереди, если есть,
- else, очередь в P-Queue.
Я использую поток домохозяйки, чтобы удалить устаревшие / просроченные соединения в очереди и порождать новые соединения, чтобы сохранить минимальное количество соединений в соответствии с настройкой.
ПОТРЕБИТЕЛЬСКАЯ очередь
Он будет заполнен экземплярами FutureTask.Приложения, использующие мой DBCP, будут вызывать
Connection conn = dbcp.getConnection(long timeout);
, что,
- сначала создаст Consumer FutureTask,
- удалит первый элемент в P-очереди, еслиany,
- else, очередь в C-очередь,
- блокировка на .get (тайм-аут) до тех пор, пока он не будет «продан» продюсером или тайм-аут, который когда-либо наступит раньше.
Мой вопрос
Можно ли еще улучшить этот дизайн?Есть какие-нибудь заметные недостатки?
Мой приоритет - стабильность в среде параллельного использования.Из моего текущего тестирования я узнал, что требуется синхронизация с обеих сторон, так как задействованы 2 очереди.
Сейчас я изучаю такие идеи, как:
- сократить 2 очереди в1 дек (хотя у меня есть проблемы с размышлениями о том, как заставить P-сторону аннигилировать C-сторону)
- создать синхронизированный поток аннигиляторов, избавляя от необходимости проверять друг друга PRODUCER и CONSUMER.