Варианты, которые первыми «пришли в голову»:

Большущее СПАСИБО!!! =)) Очень приятно! =))

Извинюсь… еле запостил статью в таком объеме. Чуть больше и Хабр «ни в какую». Потому и сократил статью. Пришлось урезать: практическое применение (кому интересно — сами найдут) и код.
Зато авторский source code прилагается: тут. Он очень сильно коррелирует с тем, что изложено в статье. Разобраться с ним — пару часов удовольствия. =)

Ни пуха, ни пера! =)

На Хабре уже проскакивали статьи по данной тематике:
1. Face Detection на джаве — это просто!
2. В поисках НЛО. Детект объектов на изображении

А основное ядро, вероятно, построенно на основе метода «Viola — Jones» (2001, pdf), он в OpenCV реализован.

_{Извиняюсь… (не дописал)}

не могли бы Вы, пожалуйста, снизу кратко подытожить в какой-нибудь сводной таблице «отсутствие защиты» у представителей вышеуказанных систем (у кого они имеются). Просто, тогда бы статья носила бы не тольго академический характер, но имела бы и непосредственную практическую ценность.

Спасибо.

Хорошая статья. Последовательно и грамотно изложено, а объем информации
(В рамках курса по изучению «Криптографии» в университете, все вышеописанное изучается около года).

Более подробно и так же не менее интересно описано в книге Венбо Мао Современная криптография. Теория и практика, с кратким введением в эллиптические кривые (ГОСТ Р 34.11-94) и прочее… Только там читать побольше =)

Дмитрий, у Вас вверху статьи написано:

Защита (или отсутствие защиты) от различных типов атак демонстрируется на примере протоколов популярных сегодня систем: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa и PayPal (платёжные системы), а также OpenID, OpenAuth, OAuth (децентрализованная аутентификация).

В документации к Drawbridge автор явно написал: «Class diagrams need to be exported as Jpeg images before the Drawbridge component can integrate the diagrams with the documentation.» Пока самостоятельно выдергивать jpg, видимо, Drawbridge не приучен.

На этот счет на stackoverflow есть неплохая заметка, которая ведет на блог msdn. =)

Вот еще пример подобного «3d»: 3DBazar.
10 минутный manual как делается такая моделька… придется повозиться =)

Спасибо! =) Польщен.
Знали бы Вы, что со мной творилось когда я дописывал вторую часть… =)

К сожалению, мне пока не довелось поработать с Teradata.
Впрочем, если как-нибудь представится возможность поработать с этой системой — с меня статья =)

Спасибо Вам за подсказку!

Большое Вам спасибо за развернутый комментарий!

С удовольствием над этим подумаем. =)
С момента написания статьи многие вещи в построении Transport level OLTP уже пересмотрели.

Все вышеизложенное в статье с самого начала не претендовало на production решение, так и, выясняя по ходу дела больше подробностей про внутрености такого подхода (тем более модуля), понятно насколько все далеко от идеала!

Будем изучать дальше.

Так же любопытно попробовать обезопаситься от «отваливания» Oracle через ихнюю же технологию TAF (Transparent Application Failover), чтобы при «смерти» одного узла (почти) мгновенно он переназначил Virtual IP другому и тот ответил, что все плохо. TCP timeout будет незначительным. Только для таких экспериментов наверное нужно будет поднять среду Oracle RAC. =)

А идея про Connection pool звучит очень заманчиво!

Согласен. =)

Только я имел ввиду несколько иное. Мы когда в числе 3-х человек на первых курсах захотели «подтянуться» в олимпиадном программировании, собирались после пар и определили порядка 10 различных типовых задач: всевозможные извращенные сортировки, переборы, динамика, графы, вычислительная геометрия, деревья, (длинная) арифметика,… Их разделили между собой примерно поровну. Чтобы все в команде зналось наизусть.

При выступлении стратегия была проста: 1 кодит, 1 на листочке фигачит в коде следующее решение, оставшийся контролирует / учавствует в конструктивной критике «рождаемого» алгоритма. Потом циклически роли меняются. Т.е. получалось что почти в любой момент: у кодера есть «наблюдающий», чтобы меньше было опечаток в реализации, и у «генератора решения» есть критик. Приблизительно по такой схеме нам удавалось успешно выступать. Есть еще некоторые тонкости — но это «много букаф».

Интересно, как Вам удавалось работать в команде.
Если вдруг пока свежи воспоминания, у Вас получится интересный рассказ о командной работе. =)

Не обязательно именно про ACM ICPC. Мне просто любопытно, каким образом выглядело участие в ACM в других командах изнутри. Имхо — это чуть ли не самый важный опыт таких олимпиад. =) Мне лично до сих пор пригождается.
Если вдруг мысли сами сформируются в интересный рассказик касательно этой стороны олимпиадного программирования — с удовольствием бы почитал. Просто мое пожелание. =)

Спасибо Вам за отзывчивость! =)

Поддерживаю автора в его начинаниях!
Сам несколько лет «играл» в ACM ICPC. Если будет возможность осветить, лично меня, теперь больше всего интересует правильная стратегия подготовки команды к олимпиаде, аспекты командной игры, как распределили роли к выступлениям и обменивали знаниями при подготовке. Если это не NDA, с удовольствием про это бы почитал. =)

Подобных «а если...» очень много, но ведь с чего-то нужно начинать. Статья затевалась ради того, чтобы услышать конструктивную критику. В открытом доступе, т.к. промежуточные результаты вполне могут оказаться полезными тем, кто не близко знаком с nginx, lighttpd. Уже немало поднималось вопросов, что бы выбрать и как реализовать (модуль, fastcgi) highload?

Спасибо за Ваш профессиональный и конструктивный подход.

вам придется расковыривать OCI и переносить из нее точку синхроноизации в epoll_wait в nginx. Да, я верю что это возможно, но есть подозрение что придется этот OCI переделать.

Расковырять OCI не получится, Oracle не раскрывает исходники. Если альтернативных вариантов не будет, то «допилить» попробуем nginx, благо код очень осмысленный и отлично читается. За наводку на epoll_wait спасибо!

И плохо что вы не написали что это только прототип. И в жизни это использовать нельзя.

Эта мысль подается и в заголовке, и в тексте. Все вышенаписаное — лишь эксперимент.
Претендовать на best practices по nginx даже и в мыслях не было.

Непосредственно в данных примерах модуль тоже блокируется синхронными вызовами к БД.

Асинхронные вызовы на OCI мы планируем использовать в дальнейших опытах.

Большое Вам спасибо за советы!
Признаюсь действительно был не прав в некоторых местах:

1. Тут действительно лучше подошло бы лучше вроде:

1.  select count(*) into l_cnt
2.     from dual
3.   where exists ( select NULL
4.                     from emp
5.                   where sal > 4000 );

* This source code was highlighted with Source Code Highlighter.

или

1. begin
2.  select id
3.   from emp
4.   where sal>4000 and rownum <= 1
5. exception
6.   when no_data_found then
7.      raise_application_error(-20010, 'Not found');
8. end;

* This source code was highlighted with Source Code Highlighter.

Tom Kyte так же советует вариант через for.

2. Неявные курсоры конечно лучше, но я ими воспользовался, чтобы одновременно залочить строчки FOR UPDATE, посмотреть есть ли в них данные (чтобы сообщить об этом клиенту) и по ним же обновиться. Так делают (ниже в комментах). Конструкция:

1. select id
2.  into l_var
3.  from anytable
4. where id = 123
5.   for update;

* This source code was highlighted with Source Code Highlighter.

не скомпилируется.

3. Пачками не коммитили, чтобы БД нагрузить и фиксировать все выполненые транзакции (вдруг БД упадет)

4. Excetion действительно лучше. My fault. Какая-то привычка из С++ сыграла, там иногда пытаются избегать exception т.к. они занижают производительность и их применять стараются только в случае явных ошибок программ.

Для примера в UPD привели по-настоящему страшный код на OCI. Тут мы и сами боимся… =)
В окончательном варианте, конечно, спрячем во wrapper.