Pharo и многонитевый FFI

Добрый день.

Решил рискнуть здоровьем и сделать то, что я сам же и осуждаю - задать вопрос без предварительного гугления и чтения ньюсгрупп. Но фаровы ньюсгруппы по-настоящему страшны, а ежедневного чтения настолько много, что ещё и на них меня не хватает..

Мне хочется соскочить с VW на Pharo (ввиду бесплатности последнего, чтобы убрать беспокойство по этому поводу). Но, что меня поражает, за все эти десятки лет (включая историю Squeak'а), полноценной поддержки (интересующих меня) СУБД так и не видно. Т.е. Oracle, DB2, Interbase/Firebird. Я не раз подумывал заняться сам. Если бы интерфейс к внешним вызовам был в духе VW или VAST'а, и занялся бы. Но вызовы FFI, как я читал, выполняется в той же нити, что и VM. Это сразу же убивает весь смысл. Для вебсервера это абсолютно неприемлемо. SQL-запросы могут выполняться достаточно продолжительное время, но при этом сервер не имеет права висеть, он должен отвечать на http-запросы других пользователей.

SqueakDBX сам по себе был сомнителен, но с многонитевостью они вообще провалились. Использование плагинов кажется мне чрезмерно сложным - это надо будет углублять около-C-шные знания и т.п., что само по себе может затянуться на месяцы, проще на VW оставаться.

Не так давно (но, наверное, год уже прошёл) я видел сообщение от Миранды, что он сделал многонитевый FFI. Как сейчас обстоят дела? Работоспособно ли оно? Есть ли более-менее приличная документация?

--
http://groups.google.ru/group/sugr

Нет. Ни в VW, ни в VAST'е не то же самое. У Pharo/Squeak один клиент подвесит всех. Имидж не будет ни отвечать на http-запросы любых клиентов, ни перерисовывать GUI, пока SQL-запрос не отработает. Точнее, так подвиснут и VW с VAST'ом... если не использовать tthreaded API.У них-то он есть.

--
http://groups.google.ru/group/sugr

Это они обещали когда-то, что блокировать не будет. Потом я читал, что для Oracle у них это не работает.
-- 

Поддержки DB2 нет. И сама по себе штука какая-то сомнительная.

Я помню, что у них (SqueakDBX) на сайте была табличка, где асинхронность поддерживается, а где нет. Старый squeakdbx.org подарили сквоттерам, а новый DBXTalk.org не завели.

А посмотрите на http://www.linuxnetworks.de/doc/index.php/OpenDBX/C_API/Usage. Посмотрите, как предлагается в OpenDBX работаь с параметрами:

int len;
char query[256];
char qstr[] = "SELECT * FROM mytable WHERE uid = '%s'";

if( ( len = snprintf( query, 256, qstr, to ) ) > 0 && len < 256 )
{
    if( ( err = odbx_query( handle, query, len ) ) < 0 )
    {
        fprintf( stderr, "odbx_query(): %s\n", odbx_error( handle, err ) );
        return err;
    }
}

Это может казаться нормальным только то... не знаю даже, кому. Людям, которые с серьёзными базами данных и СУБД не работают.
Вопрос не только в опасности SQL injection (это можно обойти), но и в огромном вреде для производительности. 


Должна быть возможность один раз за-prepare-ить statement с параметрами, затем его многократно вызывать.
Хранимые процедуры, опять же.

Предлагаемый пакет ODBC из той же оперы. Ну, я бы доработал его до приемлемого уровня, но "асинхронность"-то откуда взять?

--
http://groups.google.ru/group/sugr

Альтернатива? Делать, как в VW и VAST'е.

--
http://groups.google.ru/group/sugr

Почитайте, к примеру, книги Тома Кайта, про Oracle. Да, компиляция одного SQL-выражения кажется совершенно безобидной. Подумаешь, малые доли секунды. Но когда это идёт потоком от многих пользователей, последствия ужасны (не преувеличиваю). Кайт это даже на простейших примерах демонстрирует. Одна из важнейших проблем - эта операция не параллелится на сервере Oracle. Т.е., когда один юзер компилирует SQL-выражение (hard parsing), другие не могут, хоть там 128 ядер. Но дела даже хуже, когда поток hard parsing идёт от всего двух юзеров, производительность с точки зрения одного падает куда более, чем вдвое, чем когда работает один. Для ораклистов это вообще общее место. Для DB2 дела обстоят несколько менее ужасно, но всё равно prepare рекомендуется (если не вспоминать о Static SQL).

Разумеется, здесь речь идёт о потоке быстровыполняющихся запросов, отличающихся параметрами (то, что характеризует вебсервер). Для небольшого количества очень медленно выполняющихся запросов, наоборот, выгодно использование литералов (прямая подстановка параметров), поскольку этим может воспользоваться оптимизатор.

Я, конечно, понимаю, что черт, не мое дело... Но.
1. При планирующейся большой нагрузке еще узким местом будет
количество соединений с SQL-сервером. Их просто может на всех не
хватить. Так если столько пользователей лупит запросами, то как это
решать предполагается? Будут ждать очереди, пока из пула свободное
соединение отдадут?
2. Если серьезные базы, серьезная нагрузка, серьезные проекты. Вам не
страшно? Проект Pharo, конечно, неплохо развивается, но использовать
его в коммерции... Можно слишком много времени потратить на
допиливание. На фоне оракла, железа, стоимость лицензии VW просто
потеряется.