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

Во-первых, я разрабатываю свою собственную реализацию DBCP (пул соединений с базой данных), как таковой,

Я не приму никаких предложений по использованию стороннего DBCP, такого как c3p0.

Я использую модель проектирования «производитель-потребитель» в качестве основного шаблона для своего DBCP.

             PRODUCER | CONSUMER
Pn, ... P3, P2, P1 >>   << C1, C2, C3, ... Cn

Как для производителя, так и для потребителя я использую очередь LinkedList.

ПРОДЮСЕР Очередь

Он будет заполнен максимальным числом экземпляров SQLConnectionWrapper. Я предпринял шаги, чтобы убедиться, что соединения в очереди уникальны. После .close() соединение будет,

  • сначала удалить первый элемент в C-очереди, если он есть,
  • в противном случае поставьте очередь в P-Queue.

Я использую служебный поток для удаления устаревших/истекших соединений в очереди и для создания новых соединений, чтобы сохранить минимальное количество соединений, как настроено.

ПОТРЕБИТЕЛЬ Очередь

Он будет заполнен экземплярами FutureTask. Приложения, использующие мой DBCP, будут вызывать

Connection conn = dbcp.getConnection(long timeout);

которые бы,

  • сначала создайте Consumer FutureTask,
  • удалить первый элемент в P-очереди, если он есть,
  • иначе, очередь в C-очередь,
  • блокировка .get(timeout) до тех пор, пока он не будет «накормлен» производителем или тайм-аутом, что наступит раньше.

Мой вопрос

Можно ли еще улучшить эту конструкцию? Какие-то заметные недостатки?

Мой приоритет — стабильность в среде параллельного использования. Из моего текущего тестирования я узнал, что требуется синхронизация с обеих сторон, поскольку задействованы 2 очереди.

Сейчас я изучаю такие идеи, как:

  • уменьшить 2 очереди в 1 очередь (хотя мне трудно думать о том, как заставить P-сторону уничтожить C-сторону)
  • создайте синхронизированный поток аннигилятора, избавив PRODUCER и CONSUMER от необходимости проверять друг друга.

java database queue connection-pooling producer-consumer
person Augustus Thoo    schedule 10.11.2011    source источник
comment
по какой причине вы используете связанный список в качестве очереди, а не одну из многих импликаций очереди в j.u.c?   -  person Matt    schedule 11.11.2011
comment
Проекту 1 неделя. Я использую LinkedList, потому что проект находится на стадии Proof-Of-Concept. Кроме того, проблемы с синхронизацией, обнаруженные при тестировании, носили внешний характер. Переход на j.u.c. придет позже.   -  person Augustus Thoo    schedule 11.11.2011

Ответы (1)


arrow_upward
1
arrow_downward

Поскольку вы сказали, что не будете принимать предложения сторонних пулов. Я думаю, вы имеете в виду любой сторонний пул соединений.

Вы можете посмотреть что-то вроде пула соединений Apache Commons, который предоставляет возможности объединения для любой объект. Поэтому, хотя я не хочу обидеть вас и не хочу обескураживать вас, я думаю, что вы пытаетесь заново изобрести велосипед.

Сказав это, приведенная выше ссылка дает дизайн общего пула очень высокого уровня. Узнайте, как использовать пул, и вы получите четкое представление о том, что происходит, и поможет вам с вашим дизайном.

person Ravi Bhatt    schedule 10.11.2011
comment
Ни один не взят. Эта дизайнерская идея оригинальна для меня и началась на прошлой неделе. Ранее я рассмотрел и протестировал реализацию DBCP в открытом исходном коде Openfire. IMO, я обнаружил, что его дизайн не распределяет соединения между ожидающими потребительскими потоками. Следовательно, я использую очередь, чтобы и производитель, и потребитель могли управляться по принципу «первым пришел — первым обслужен». - person Augustus Thoo; 11.11.2011
comment
Я хочу сообщить, что поток аннигилятора работает и поддерживает синхронизацию между ПК. В целом, проект завершен, и я должен сосредоточиться на других проектах. Я по-прежнему приветствую любые предложения по этому вопросу. Если в ближайшие 2 недели обновлений не будет, я рассмотрю возможность закрыть этот вопрос как оставшийся без ответа. - person Augustus Thoo; 14.11.2011