Вопрос: Зачем регистрировать out-параметр?

Ответ: Вы же видите, что в него не кладется значение, он же возвращаемый. А если вы его не зарегистрируете, она скажет: «О! Это параметр! Ты данные мне не дал!». Правильно? И будет ошибка.

И вызвали execute(). Здесь можно было бы вызвать и какой-нибудь другой execute(). Это не важно.

И еще один функционал, который был добавлен в CallableStatement. Это вот этот последний get(). Дело в том, что не было в интерфейсах, которые мы смотрели до этого каких либо get(). out-параметр нужно теперь как-то прочитать. Вам же вернули данные. А где они? Читаете через get(). Вы знаете какого он типа. Вы его сами зарегистрировали как Integer. Поэтому читаем как getInteger(). И «1» - это номер, он первый. Т.е. он зарегистрировался первый. И вот он читается.

Значит смотрите. В этих параметрах вы видите знак вопроса, но на самом деле есть именованные параметры. В интерфейсе некоторые разные set (которые для параметров) – они есть по номеру, а есть по имени. Так вот. У меня были ребята, которые пробовали по имени и в MSSQLэто не поддерживалось, а в Oracleименованные параметры работают. Поэтому тут функционал в JDBCесть, но не все компании это поддерживают.

Давайте теперь вызовем хранимую процедуру. Давайте сделаем новый проект. В новом проекте скопируйте следующие строчки, чтобы нам это не набирать руками.

Создать проект «sql3». И первое, что мы должны сделать – это поменять интерфейс. Мне не нравится название «prepareCall()». Как-то он не вписывается в PreparedStatement. Они не сочетаются. Естественно в параметре метода prepareCall() будет запрос «sql», в котором будет храниться наш запрос. В запросе и инициализируем запрос. Для этого нужно найти хранимую процедуру с ее названием. preparedCall() возвращает CallableStatement. Поэтому нужно объявить переменную CallableStatement. Я попробую здесь это сделать в одну строчку «CallableStatementst».

Теперь нам нужно имя хранимой процедуры. И обратите внимание, что эти фигурные скобки являются частью синтаксиса.sakila.inventory_in_stock

Это пример с MSSQL. Мне задание: реализовать это для MySQL

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

Это вот то, что мы посмотрели. Это последний интерфейс, который предоставляет нам JDBC, и называется он CallableStatement.

Тразакции в JDBCApi

Идем далее… У нас осталось несколько слайдов. Нам предлагают задуматься все-таки повнимательнее про транзакции, commit() и тому подобное.Здесь есть несколько позиций, где показано, что вы должны сделать:

Вот первая строчка. С объекта Connectionвы отключаете setAutoCommit(false). Это значит, что теперь каждое действие (или набор действий), которое вы выполняете, вы должны подтверждать вызовом commit(). И тогда транзакция завершается с успехом. И данные будут изменены в БД. Если вы не вызываете commit() или вызываете rollback(), то происходит откат. Обратите внимание, допустим можно сделать пять действий, произвели точку сохранения, потом пошли три действия. И откатить можно всю транзакцию, и тогда ничего не надо писать; а можно откатить до точки сохранения. Ну допустим, что вы еще раз захотите это сделать повторно. Откатили – не получилось. Еще раз попробовали – получилось. Ради Бога. Есть возможность управлять до какого этапа откатывается ваша транзакция.

Ну и, конечно, здесь есть один важный момент. Видите, пункт под названием «Выбираем уровень изоляции транзакций»? Все дело в том, что по умолчанию его устанавливают не очень высоким и это зависит от задачи. Может быть вас такой вариант не устроит. Можно посмотреть уровни изоляции в документации (см. нижнюю картинку).

Какой стоит по умолчанию? Поумолчаниюстоит TRANSACTION_ READ_ COMMITED.

Вопрос: Что это сие означает «уровень изоляции транзакции»? Вот представьте, что у вас идет транзакция. Она читает данные, меняет их и делает много чего еще. А что все остальные? Отдыхают и ждут? Поэтому вопрос такой. А другие транзакции могут те данные, которые в первой транзакции «участвовать, читать, менять»?

Ответ: Вот этот уровень изоляции и отвечает на вопрос могут или нет. И что именно могут.

Допустим, у вас одна транзакция снимает деньги со счета. У вас там было 100, а она снимает 50. Транзакция говорит: «я снимаю 50», но она еще не завершилась. Сколько там денег на счете? 100. И если мы дадим другой транзакции видеть данные, то она возьмет 100 и снимет. И завершится. А потом завершится первая транзакция. И сколько вы будете должны? Понимаете, да? И вы еще окажетесь им должны.

Поэтому для финансовых операций – это очень неприятный момент. А что произошло в данной ситуации? Почему возникла такая накладка? А дело в том, что первая транзакция изменила данные, но еще их не приняла. Это и называется uncommitted. Незавершенные и незафиксированные в БД данные. А другая транзакция читает незавершенные данные. Видите? TRANSACTION_ READ_ UNCOMMITED. Это недопустимо. По сути это называется «грязное чтение». Мы читаем данные, которые находятся в каком-то неопределенном состоянии. И это считается совсем плохо. Поэтому по умолчанию идет уровень изоляции «TRANSACTION_ READ_ COMMITED». Потому что другая транзакция не сможет прочитать состояние «сколько денег на счете, пока первая не скажет commit()».

Но это не предотвращает другие проблемы. Например, есть проблема «неповторяющегося чтения». Что это такое? А представьте себе следующую ситуацию. Одна транзакция меняет на счете сумму (причем делает это несколько раз), и делает commit() несколько раз. А другая транзакция читает деньги и говорит: «сколько на этом счету? 30, 50, 40». Данные разные. И сколько их там? Среднее брать? Вот это и есть «неповторяющееся чтение». Вас это волнует? Это зависит от предметной области. Если вы скажете «да», то это важно, т.к. эту проблему нужно исключить. Вы ставите еще один более высокий уровень изоляции «TRANSACTION_ REPEATABLE_ READ». Это значит, все остальные, кто будет работать в этой системе будут ждать дольше. Но и при таком уровне могут появиться «фантомы». «Фантомы» волнуют вас? Если волнуют, то ставите «TRANSACTION_ SERIALIZABLE»и тогда никаких накладок происходить не будет. Но тогда, простите, и производительности у вас не будет. Тут как коромысло. Хочешь надежность, потерял производительность, и наоборот. Выбирать вам вместе с вашими специалистами по БД.