Как улучшить дизайн этого пула соединений?

#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 недели не будет обновлений, я рассмотрю возможность закрытия этого вопроса как оставшегося без ответа.