#java #database #queue #connection-pooling #producer-consumer
#java #База данных #очередь #объединение в пул соединений #производитель-потребитель
Вопрос:
Во-первых, я разрабатываю свою собственную реализацию DBCP (объединение пулов соединений с базой данных) как таковую,
Я не приму никаких предложений использовать сторонний DBCP, такой как c3p0.
Я использую модель проектирования производитель-потребитель в качестве основного шаблона проектирования для моего DBCP.
PRODUCER | CONSUMER
Pn, ... P3, P2, P1 >> << C1, C2, C3, ... Cn
Как для производителя, так и для потребителя я использую очередь LinkedList.
Очередь ПРОИЗВОДИТЕЛЯ
Он будет заполнен максимальным количеством экземпляров SQLConnectionWrapper. Я предпринял шаги, чтобы убедиться, что соединения уникальны в очереди. После .close() соединение будет,
- сначала удалите первый элемент в C-очереди, если таковой имеется,
- в противном случае, поставьте в очередь P-Queue.
Я использую поток house-keeper для удаления устаревших / истекших подключений в очереди и для создания новых подключений, чтобы сохранить настроенное минимальное количество подключений.
Очередь ПОТРЕБИТЕЛЯ
Он будет заполнен экземплярами FutureTask. Приложения, использующие мой DBCP, вызывали бы
Connection conn = dbcp.getConnection(long timeout);
что бы,
- сначала создайте потребительскую FutureTask,
- удалите первый элемент в P-очереди, если таковой имеется,
- в противном случае, очередь в C-queue,
- блокировка файла .get (тайм-аут) до тех пор, пока он не будет «подан» производителем, или тайм-аут, который всегда наступает первым.
Мой вопрос
Можно ли еще улучшить этот дизайн? Какие-либо заметные недостатки?
Мой приоритет — стабильность в среде параллельного использования. Из моего текущего тестирования я узнал, что требуется синхронизация с обеих сторон, поскольку задействованы 2 очереди.
Прямо сейчас я изучаю такие идеи, как :
- сократите 2 очереди в 1 очередь (хотя мне трудно думать о том, как заставить P-сторону уничтожить C-сторону)
- создайте синхронизированный поток уничтожения, устраняющий необходимость проверки ПРОИЗВОДИТЕЛЕМ и ПОТРЕБИТЕЛЕМ друг друга.
Комментарии:
1. есть ли причина, по которой вы используете linkedlist в качестве очереди, а не одного из многих реализаций очереди в j.u.c?
2. Проекту 1 неделя. Я использую LinkedList, потому что проект находится на стадии проверки концепции. Кроме того, проблемы синхронизации, обнаруженные в ходе тестирования, носили внешний характер. Изменения в j.u.c. появятся позже.
Ответ №1:
Поскольку вы сказали, что не примете никаких предложений сторонних пулов. Я предполагаю, что вы имеете в виду любой сторонний пул соединений.
Что вы можете посмотреть, это что-то вроде пула соединений apache commons, который предоставляет средства объединения для любого объекта. Итак, хотя я не хочу вас обижать и не хочу вас обескураживать, я думаю, вы пытаетесь заново изобрести колесо.
Сказав это, ссылка выше дает очень высокоуровневый дизайн общего пула. Проверьте, как использовать пул, и вы получите четкое представление о том, что происходит, и это также поможет вам с вашим дизайном.
Комментарии:
1. Не принимается. Эта идея дизайна является оригинальной для меня и была начата на прошлой неделе. Ранее я рассмотрел и протестировал реализацию DBCP в Openfire с открытым исходным кодом. ИМО, я обнаружил, что его дизайн несправедливо распределял соединения между ожидающими потоками-потребителями. Следовательно, я использую очередь, чтобы и производителем, и потребителем можно было управлять в порядке живой очереди.
2. Я хотел бы сообщить, что поток уничтожения работает и сохраняет синхронизацию между P-C без изменений. В целом, проект завершен, и я должен сосредоточиться на других проектах. Я по-прежнему приветствую любые предложения по этому вопросу. Если в ближайшие 2 недели не будет обновлений, я рассмотрю возможность закрытия этого вопроса как оставшегося без ответа.