Для того, чтобы приделать фронт, надо полностью перенести в него офигенную тучу бизнес-логики. Это по сути проект "разработайте мне такую же систему заново и чтобы во всех тонкостях была совместима со старой". А inmemory в десятом оракле как-то не особо.


С этим проблем не было. Процессоры по большому счёту простаивали. Как я уже сказал, бутылочным горлышком становился объём дискового ввода-вывода. Для простоты картины можно считать, что записи сначала делался insert, потом в зависимости от параметров, настроек итп. сколько-то раз делался update, и в конце - delete. То, с какой скоростью сервер был способен писать логи этих операций, по сути и определяло нагрузку, с которой система могла справиться. С какой степенью параллельности делались эти апдейты - дело десятое. Ну то есть её конечно тюнили ещё до меня, выскребая результат получше, но таким образом итоговый результат менялся на проценты, а интересовали разы.


Я и не виню яву. Как бы объяснить на пальцах.... Ну вот смотрите, есть api с операциями типа "сохранить кортеж по id" и "прочитать кортеж по id". При вызове его на реальной системе с реализацией через оракловые таблицы оно работает со скоростью тысяча попугаев в секунду. При этом 90% нагрузки на сервер - это работа этой реализации. Я пишу на яве модуль, реализующий то же api, которой на том же железе отрабатывает ту же тестовую последовательность вызовов со скоростью, например, восемьдесят тысяч попугаев в секунду. После этого я подгружаю этот модуль в оракловую базу, заменяю им реализацию через таблицы - и получаю скорость двадцать пять попугаев в секунду. Матерюсь, выношу этот модуль в отдельное приложение, крутящееся рядом с базой, делаю из базы доступ к этому приложению - и всякими финтифлюшками ухитряюсь в итоге добиться скорости аж двести попугаев в секунду, причём само приложение занимает ноль процентов, а сто процентов уходят на доступ к нему из оракла. Не буду описывать дальнейшие эксперименты, не в них суть. В этом месте я делаю вывод, что ява-машина включена в СУБД, мягко говоря, через задницу.


Да подключались они, только толку....


Угу. Именно так та система и была реализована.


Нет, не удавалось. Там просто требовалось выполнить N dml-ей, каждый из которых писал в среднем K байт в redo. Когда N*K начинал превышать возможности дисковой подсистемы - серверу предсказуемо плохело, а клиенты без восторга относились к идее уменьшать N методом "купить новый сервер и перенести половину нагрузки туда".


О, да. Это одна из тех выдающихся глупостей реализации, про которые я сначала даже не подозревал, что так могли сделать. Мало того, эта ява-машина ещё и практически однопоточная, и ни хрена не имеет адекватных механизмов общения с ява-машинами других сессий в той же СУБД.


Откуда вы выдумали "загруженную многопользовательскую систему с дефицитом оперативной памяти"? Чем она была загружена - я уже не раз повторил. Многопользовательскую.... ну сколько сконфигурили сессий, столько и пользовательскую. Дефицита памяти там не было. И дефицита процессоров тоже не было. Сервер стоял и скучал, пока надрывался ввод-вывод, который забивали бешеным количеством байт от бешеного количества update-ов временных данных, которым через долю секунды делали delete и которым нахрен не был нужен никакой acid, никакое восстановление итп.

booby,

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

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

Не уверен, что это хороший путь. Оракл много лет занимался тем, что рожал монстровые языки и подходы, от Pro*C до Oracle Forms. Развить PL/SQL до уровня, кроющего яву... тут, имхо, есть два основных варианта исхода. Вариант первый: получится очередной жуткий монстр. Примерно как те ООП-шные возможности, которые уже внедрены в язык. Вариант второй: получится хороший, даже замечательный язык. Ни с чем не совместимый, практически без библиотек и практически без поддержки со стороны инструментальных средств. Думаете, оправдано будет сидеть и писать на нём очередные реализации XML парсеров или библиотек работы с изображениями?

В общем, думаю, что перенести достоинства PL/SQL в яву легче, чем перенести достоинства явы в PL/SQL. И раз уж Оракл обзавёлся такой собственностью как java - было бы логично использовать её по полной программе.

Кто про что, а вшивый про баню. И ведь ещё двадцать раз напишет - и сам поверит, что так всё и было, он своими глазами видел