Yo.!sqlj в db2 это внешний и чуждый для субд процесс который лезет в базу через тот же JDBC. просто писанины чуть меньше. Забавно, а почему взята статья именно от 2003 года? Там еще за 2000 найти можно, еще раритетнее :)
На самом деле, даже в приведенной Вами сказано, что SQLJ использует коннект от JDBC для получения ConnectionContext, а не "лезет через него в базу". А в случае SP и его не использует - коннект-то там уже есть.
JDBC работает с динамическими запросами, а SQLJ обращается к уже скомпилированным пакаджам. Еще раз - при прекомпиляции запросы SQLJ превращаются фактически в вызовы "плана № X" на сервере, JDBC тут вообще никакого участия не принимает.
По поводу "чуждого" процесса - в DB2 есть 2 режима работы Java драйвера - type 2 и type 4. Type 2 является прослойкой над нативным для ОС клиентом, type 4 от него и ОС независим и сам писан на джаве. Для SP используется именно type 2, т.е. Java процедура работает практически как fenced процедура на C, например. Т.е. при локальном коннекте (в т.ч. в случае SP) вместо сетевых прелестей используется нормальное межпроцессное взаимодействие в рамках ОС (через shared memory, например).

2 Yo.!
К слову, при компиляции процедуры на SQL PL создают в БД фактически такие же пакаджи, содержащие скомпилированные в планы статические запросы и логику. Просто вызываются они тем же процессом, что и выполняются, а не "сторонним". Так что по сравнению с SQL PL "попадалово" для Java тут только на переключение контекстов и передачу данных в ОП.

Yo.!почему именно с жавой ? вот у мсскл нет вменяемого варианта с жава, зато есть с .Net. важно не чем конкретно решается задача, а на сколько эффективно и удобно.К слову - любители могут писать SP/UDF на .Net и в DB2 :)
Yo.!но даже если говорить о жава в том же оракле жава интегрирована в ядро субд, т.е. более тесно чем у db2.Что значит "интегрирована"? Как я понимаю, у Оракл просто есть своя имплементация JVM, поставляемая с СУБД. Но у IBM тоже своя JVM и свой Java SDK, тоже поставляемые с DB2 и работающие с ней. Куда "интегрированней"? Или Оракл сам исполняет байт-код, в обход своей JVM? Тогда Java там должна быть быстрее PL/SQL - он-то, бедный, VM использует! ;)
Более того, бесплатно можно скачать IBM Data Studio, после чего в единой среде Eclipse со всеми ее вкусностями писать SP ( в т.ч. с удаленной отладкой) как на SQL PL, так и на Java. И там же с БД работать.

Yo.!покажите более подробное описание, я не лингвист и фразу "The SQLJ runtime relies on a JDBC driver to obtain a database connection in order to access the database." понял, что access тоже тоже идет по jdbc.В том контексте сие значит, что отдельное Java приложение использует JDBC для коннекта. Дальше SQLJ получает ConnectionContext и живет своей жизнью, используя JDBC только для динамических запросов. Подробнее здесь , но там много. :) В случае Java SP коннект уже есть, просто берется default. Еще раз - у JDBC и SQLJ общий драйвер . Работая в режиме type 2 он является надстройкой над клиентом DB2, т.е. в случае SP - над собственно native API сервера.
Yo.!мое рассуждение просто - раз жава отдельный процесс, чуждый к SQL значит от нее и к ней нужно гонять входящие/исходящие данные как не крути. оракл же может биндить pl/sql переменные сразу, не гоняя их через тормознутый jdbc и не конвертируя не совпадающие форматы.Опять - DB2 jdbc type 2 не более тормознутый, чем C CLI, например. И "гонять данные" нужно не больше, чем в SP на C, например. Или при native compilation PL/SQL (например, как вроде самый быстрый вариант PL/SQL) в вызовах процедур передача параметров не используется, оно само там как-то? :)
А приведение типов - да, для сложных типов нужно . И что, это большие потери? Кажется, мы договорились, что логику массированной обработки данных лучше делать в SQL PL, а внешние задачи - на Java.
Yo.!не понятно чем заменить %rowtype и иже с ним, никаких bulk insert/collect, отслеживаний зависимостей и сотни других важных фич.Трудно сказать, не разбираясь в Оракл, но навскидку:
1. %rowtype в Java - видимо ничем. Тем не менее, можно работать с возвращаемым rowset или параметром типа cursor. В SQL PL заменим на row data type .
2. bulk insert - в Java на batch update , который не только INSERT, но и все остальное, включая MERGE. Чем BULK COLLECT в SP лучше курсора - не понял, видимо это специфично для Оракл.
3. отслеживания зависимостей - именно для этого и существует SQLJ с хранимыми в БД package с запросами (к Oracle package и к Java package никакого отношения не имеют).
4. Про сотни важных фич - со столькими не знаком :) Но опять-таки подозреваю, что важны они именно для обработки данных, а для нее я Java SP и не предлагаю. А в самой Java как в универсальноq платформе важных фич - тьма.

Yo.!к стате в бимерском sql pl есть какой-то error handling ?А как же! Только точнее - condition handlers. Если коротко - реагировать можно вообще на SQLEXCEPTION, SQLWARNING, NOT FOUND, или на что-то конкретное, в т.ч. пользовательское событие, выдаваемое SIGNAL .
Объявляем обработчик с нужным кодом, по завершении которого произойдет EXIT (из процедуры), CONTINUE или UNDO (последний - в ATOMIC блоках). В обработчике можно сделать RESIGNAL события.
Дальше пишем собственно SP, обработчики вызываются сами при возникновении заданных условий. Примеры тут , в конце.

Наконец нашел время почитать про Oracle JVM.
Yo.!терминами ibm - в оракле жаба not fenced и живет в SGA, тесно интегрирована с типами и прочая. у db2 же интеграции по сути нет, ему по барабану даже, что там за jvm - хочешь хоть сановскую запускай, субд пофигу, кто там через драйвер jdbc/jsql лезет ...Начнем сначала - JVM есть интерпретатор намеренно простого байт-кода, плюс мусорщик, JIT и RTTI с рефлексией. Остальное - в библиотеках пакетов, к которым относится "драйвер" СУБД. Можно уточнить (или ссылочку дать) какие именно данные , с кем и по какому поводу делит сей механизм в SGA? Моей скудной фантазии не хватает, и мне кажется, что "субд пофигу" - верное описание. :)
Как я понял отсюда , основные фичи интеграции JVM в Оракл - это общий heap для read-only данных (хотя при чем тут СУБД?), управление мусорщиком шедулером Оракл и загрузка пакетов Java из СУБД. 1-е вполне соответствует not fenced Java в DB2 (с общей JVM). Остальное м.б. удобно, м.б. не очень - дело вкуса, но уж точно не решающее преимущество. И где тут SGA, или я что-то пропустил?
Yo.!это единый драйвер, он одинаково работает как c jdbc так и с sqlj, хрен с ним пусть в режиме type 2 но драйвер один и тормозной из-за жава прослойки.Теперь о драйвере DB2 - сдается мне, что тут у Вас путаница в терминах. Он "единый" только в том смысле, что упакован в единый пакет, но в него входят множество компонентов для разных режимов работы. Прочитал про 3 драйвера JDBC в Oracle:
1. JDBC Thin driver
2. JDBC OCI driver
3. JDBC server-side internal driver.
О чудо - полное соответствие с DB2! 1 - type 4, 2 - type 2, 3 - type 2 при работе на сервере (локальный коннект). Разница только в компоновке пакетов - 3 отдельных или 1 общий.
Заметим, что в любом случае "тормозная" Java прослойка есть, только в Оракл она общается с ОС не напрямую, а посредством Oracle Database libraries. Т.е. через еще одну прослойку. ;) С СУБД же они общаются примерно одинаково, причем не на уровне JVM, а на уровне "драйверов", т.е. интерфейсных библиотек.
Yo.!еще раз java stored procedures в db2 это просто syntax shugar, на которую из jvm вешать не суть важно. вся интеграция сделана на уровне синтаксиса, а не на уровне архитектуры и структур памяти. у оркла примерно так же сторед процедуры на .net прикручены.Еще раз - при чем тут JVM? Все дело в пакетах интерфейса с СУБД ("драйверах"), а не в JVM. А SQLJ является syntax shugar именно в Оракл, где он тупо превращается в JDBC вызовы:
"When your SQLJ application runs, the SQLJ run time calls JDBC to communicate with the database."
В DB2 же SQLJ, как и любой другой static SQL - принципиально другой способ работы, не использующий не только JDBC, но даже CLI (аналог OCI). Причем другой не только со стороны Java, но и со стороны СУБД. И возможная экономия ресурсов именно СУБД на выполнении запросов, а также иные вкусности, тут куда значительней затрат на копирование переменных. Кстати, о копировании.
Yo.!про что я и толкую - само. SQL движек их возьмет из структур памяти pl/sql машины. а вот db2-шная fenced жава будет их гонять копии и их преобразовывать растрачивая ресурсы.С PL/SQL - понятно, но то же самое, как я понял из Ваших утверждений, можно сказать и про Java в Oracle? Посмотрим на первый попавшийся пример :
Я правильно понял, что в случае выполнения подобного кода в Oracle Java SP объект PreparedStatement на самом деле не будет создаваться и его методы, копирующие id и salary не будут выполняться? А name получит ссылку на область внутри SGA, без копирования данных? Хотелось бы посмотреть на ссылку на такие чудеса.
Yo.!As an example, the DB2 data type VARCHAR does not exist in Java. However Java has a String object that can be used instead.Что-то я не заметил, чтобы в примере выше вместо String использовалось что-то волшебное :)

Yo.!да, вроде уже раза два до этого договорились, но вы каждый раз выпячиваете жава как альтернативу pl/sql.
херовая она альтернатива в плане серьезного перелопачивания данных, если нужно серьезно перелопачивать много данных нужен нормальный, развитый язык 4GL с серьезной интеграцией с субд.Для серьезного перелопачивания как альтернативу я каждый раз "выпячиваю" SQL PL, и все еще не очень понимаю чем именно для этого он принципиально хуже. Скажу больше - перелопачивать куда эффективнее самим SQL. И что-то внешнее отн. СУБД куда лучше по возможности делать из UDF, вызывая их из SQL, не нагружая сервер своими представлениями о процедурах перелопачивания. И только если получается криво - в SP на Java, и только для "внешних" действий. Но тема топика - именно SP.
Yo.!а жаву, если уж и использовать, то как полноценное ООП (в виде 3-tier), а не процедуры на жаве лабать.Заметьте, не я это предложил! (с) ;)
И я полностью согласен, но в рамках данного разговора считал оффтопиком, имеющим отношение к проектированию. У нас, как правило, SP и table UDF на SQL PL используются для изоляции разработчиков на всяком PHP и т.д. от не вполне понятного им SQL, т.е. для абстрагирования и разделения задач. А внутри SP - в основном запросы, без всякой надобности в "универсальном" 4GL.
Так что да - в 3-tier оно лучше, но в Oracle по поводу Java SP все-таки тоже зачем-то заморочились. :)

Yo.!не пойму в чем смысл отрицать столь очевидное? честно говоря мне не интересно обсуждать чья жава более тормознутаяВ том, что "очевидное" часто оказывается просто PR бредом, у любого вендора. И мне просто интересно разобраться в действительных механизмах работы.
А вот чья тормознутее - мне тоже не интересно. И Оракл, и IBM утверждают, что их JVM куда круче остальных, так что скорее всего примерно одинаково. :)
Намеки же на общую тормознутость жабы при наличии JIT и inline в runtime я рассматривать не буду. Все-таки не о GUI разговариваем.
Yo.!но факты очевидны - оракл переколбасил жава, как в плане архитектуры (ту же стратегию гарбадж коллектора) так и в плане структур памяти (вот ссылка о jvm в SGA/PGA) .Вот мерси, наконец-то информативная ссылка. Если я правильно ее осознал, то вся немерянная мощь переколбашивания заключается (для shared server) в выделении внутри SGA фиксированного Java pool memory, с которой и живет JVM. Особенно впечатлило:
"Because the Java pool memory size is fixed, you must estimate the total requirement for your applications and multiply by the number of concurrent sessions the applications want to create, to calculate the total amount of necessary Java pool memory. Each UGA grows and shrinks as necessary. However, all UGAs combined must be able to fit within the entire fixed Java pool space."
Делаю выводы:
1. Pool задается статически, без перебалансировки, т.е. его надо задавать с большим запасом и мириться с не оптимальным расходом на него памяти. Великолепная интеграция! :)
2. Понятно, что мусорщика переписали - раз память в SGA, ей и управлять надо с подачи Оракл СУБД, который этой SGA заведует. Мера вынужденная, и преимуществ тут не наблюдаю, т.к. pool все равно отдельный от всего остального.
Yo.!IBM же так заморачиваться не стал и гоняет обычную жаву, любую, хоть сановскую, ограничившись слегка подпиленными драйверами. если вы на полном серьезе считаете, что подпиленные драйвера, будь они хоть трижды более нативны дают основание считать что такая интеграция не менее тесна чем оракловая то аргументированный разговор у нас не получится.Я на полном серьезе со ссылками показал, что Oracle JVM с БД работает ровно так же, как и IBM JVM, с теми же 3-мя вариантами драйверов, за исключением SQLJ. Я не говорил, что кто-то более нативен, я говорил, что все одинаково. Вопросы управления памятью, как выяснилось, к интерфейсу с СУБД отношения не имеют.
Я так и не понял, почему именно "встроенная" Java является достоинством - может, просто не нашел. :) А вот недостатком в бюджетных лицензиях она может быть, т.к. тратит лицензируемые ресурсы. Да и в XE не входит.
Yo.!далее по драйверам IBM, в том самом "driver for JDBC and SQLJ type 2" , точно та же жава прослойка "Drivers that are written partly in the Java™ programming language and partly in native code.", которая на OCI нифига не похожа.Естественно, на Oracle OCI похожа DB2 CLI, а не Java-прослойка. "The JDBC OCI driver accesses Oracle-specific native code". Именно "accesses" через JNI, и в Оракл (OCI), и в DB2 (CLI). Еще раз - Java-часть тут просто прокси к OCI/CLI, для обеих СУБД. А написать "нативный" драйвер на Java без самой Java возможности нет, т.к. собственно JNI - это тоже часть Java, как и стандартная описательная часть классов JDBC. :)
Yo.!с чего вы взяли, что для sqlj в db2 используется что то другое, более нативное чем jdbc для меня так и осталось загадкой учитывая, что в доку четко сказано "The SQLJ runtime relies on a JDBC driver to obtain a database connection in order to access the database."Устал, но повторю - получить контекст коннекта от JDBC не значит использовать JDBC для собственно работы с данными, это просто стандартный для Java способ коннекта. Аналогично программа (SP) с embedded SQL на C может использовать коннект от CLI , не используя CLI собственно для работы (если не надо).
Цитата : "You can use one of six techniques to connect to a data source in an SQLJ program. Two use the JDBC DriverManager interface, two use the JDBC DataSource interface, one uses a previously created connection context, and one uses the default connection."
SQLJ не интересно, какой был коннект, он просто работает с его контекстом.
По поводу "более нативное чем jdbc" - посмотрите, скажем, Figure 2. Expansion of application layer . Видно, что SQLJ runtime работает не только мимо JDBC, но и мимо CLI, как и положено embedded SQL в DB2.
Принципиальная разница с Оракл в том, что при прекомпиляции не только проверяется синтаксис и связи, но в БД создается спец. объект - embedded SQL package , аналогов которому в Оракл нет. И если стандартный Java-пакет sqlj.runtime в Оракл дергает JDBC для выполнения SQL, в DB2 он просто обращается к выполнению определенного запроса внутри package, ничего не зная о собственно SQL этого запроса, минуя кучу стадий синт. разбора, переформулирования и, по умолчанию, оптимизации с построением плана. Фактически это прямой вызов готового плана выполнения, а не собственно запроса SQL.
Yo.!про бинд переменные в оракловой жаве однозначно не нашел (потому и не утверждал), но по косвенным признакам выглядит, что переменные гоняются от jvm к sql движку растрачивая ресурсы.Что еще раз показывает одинаковую работу JVM с БД что в Оракл, что в DB2.
Yo.!ЗЫ. если вам хватает усеченного языка для полноценного реализации логики в SP я не спорю, просто лично я предпочел бы иметь полноценный универсальный язык усеченному, раз уж я решил писать SP.Полостью согласен - вопрос вкуса. Для обработки данных я предпочитаю язык, код которого выполняется непостредственно SQL движком, а то и inline поставляется в текст запроса, а не живет на отдельной VM, как PL/SQL.