Программистское

[catpad]

Для системы реального времени (шанхайской биржи) написал Database Connection Pool со следующими обязательными условиями:

1) Число connections ограничено и меньше числа threads, которые ими пользуются (ну, это понятно), но может динамически меняться. Естественно, что только один thread может пользоваться одним connection в каждый момент времени.
2) No thread starvation - гарантировано, что каждый thread, который запрашивает connection, рано или поздно получит его наравне с другими, даже более проворными threads - это самое важное (для моей задачи) условие.
3) Гарантировано, что в каждый момент времени открыто ровно столько connections, сколько нужно, а все остальные закрыты.
4) Гарантировано минимальное число дорогих операций открытия/закрытия connection, то есть сами threads свои connections никогда не закрывают, а открывают только в случае крайней необходимости. Connection закрывается только тогда, когда им не пользуются в течение некоторого времени.
5) В случае, если в pool'е нет свободного connection, thread, который запросил connection, блокируется только тогда, когда пожелает, а не сразу после того, как он запросил connection. То есть, сразу после запроса этот thread может заняться, чем ему будет угодно, а connection, который он просит, будет тем временем его дожидаться столько, сколько нужно (когда само станет доступным, конечно). Здесь рассчитано на честность каждого thread'а - если никто из них своими connections не воспользуется, то pool рано или поздно просто опустеет. С другой стороны - это же и способ убирать лишние connections из pool'а - запрашивать и не отдавать, учитывая, что каждый connection через некоторое время закроется сам.

Очень хорошо подходит для большой задачи на интервью. Всё умещается примерно в 100 строк (Java). Приятная задача!

Comments

[khazzar.livejournal.com]

о, супер! возьму на вооружение, если что?

[catpad.livejournal.com]

Конечно, для того и пишу.
Нужны намёки на решение ?

[khazzar.livejournal.com]

да нет, сам попробую :)

[khazzar.livejournal.com]

я полтора года назад формулировал задачку, которая может вам пригодится для каких-нибудь издевательств над людьми :) в комментах вроде есть решения
http://khazzar.livejournal.com/151729.html

[catpad.livejournal.com]

Спасибо, интересно.

[lelia-br.livejournal.com]

Why not using non-blocking IO (Reactor design pattern)?

[catpad.livejournal.com]

Из описания я вижу: "The Reactor design pattern demultiplexes events and dispatches them to registered object handlers."
В моём случае thread не является Observer'ом, а наоборот сам инициирует получение connection тогда, когда ему нужно.

[lelia-br.livejournal.com]

I'll wrte in English as I type faster. In Reactor you have one object that awaits for incomming events (accpeting connections, requests to connect to someone, reading data, writing data). ONLY when there is an event the short thread processing it is created. There is a thread pool (can be adjusted to match the load), so the number of existing threads is limited. The Reactor pattern/Non-blocking IO is used to avoid having a thread per connections, which is "expensive" and can lead to DoS attacks/situations.

[execve.livejournal.com]

Требования 3 и 4 противоречат друг другу, нет?

Либо "Connection закрывается только тогда, когда им не пользуются в течение некоторого времени" и в течении этого "некоторого времени" это соединение будет бесхозным, либо "в каждый момент времени открыто ровно столько connections, сколько нужно, а все остальные закрыты" и бесхозных соединений не бывает.