Лет ми спик фром май хард

I have decided to begin blogging in two languages. Russian and English. It means that some of my posts will be translated into English.
The advantages of this decision are following:

Primo. It will be a good practise for me, and my poor English will have a chance to be improved
Secundo. My blog will not be bounded by Russian audience.
Tertio. In case I want to write something but there are no any new thoughts, I always can translate some early post.

Captain Obvious notes:
All posts in English will have tag "English". All post in Russian will be marked as "Russian"

Немного об автономных транзакциях в Oracle

Вступление.
Многие, кому приходилось работать с Oracle RDBMS, сталкивались с автономными транзакциями, которые можно использовать для обеспечения дополнительной гибкости в пакетах на PL/SQL. Если кратко, то этот механизм позволяет в любой месте выполняемого кода начать транзакцию, независимую от текущей.

Например, наша программа обрабатывает данные и попутно ведет лог своих действий в специальную таблицу. В случае, если в ходе выполнения возникла исключительная ситуация, программа откатывает все изменения и завершает работу. Вполне естественно и логично, что лог мы ведем как раз для того, чтобы посмотреть на каком шаге случилась беда. Однако, как мы узнаем, что записалось в лог, если все изменения, в том числе и записи в нашу специальную таблицу, откатываются? Вот тут-то на помощь и приходят автономные транзакции. При их использовании запись в лог совершается  в рамках отдельной транзакции, инициируемой текущей. Теперь нам безразлично, как завершилась основная транзакция - новые записи в логе никуда не денутся.


Иллюзия.
Надо сказать, что в большинстве случаев автономные транзакции используются именно таким образом. И было замечено, что у многих (хоть и не у всех) возникает некоторая иллюзия в их отношении.

Лиха беда начало

Сегодня первый раз принял участие в матче системы TopCoder - SRM 517.

Чтобы было понятно, о чем идет речь,  поясню для тех, кто не знает - на ТопКодере программисты меряются своими талантами. Периодически проводятся SRM (Single Round Match), в ходе которых конкурсантам предлагаются три задачи. Все участники разделены на два дивизиона - в первый дивизион входят те, у кого рейтинг начинается с 1200, а во второй - все остальные, включая новичков. Этот рейтинг рассчитывается по хитрой формуле относительно результатов всех остальных участников, что и создает соревновательный момент.


В первом и втором дивизионе предлагаются задачи разного уровня сложности(в первом сложнее). За первую задачу максимальное количество баллов - 250, за вторую - 500, за третью тысяча. Максимум этот является недостижимым, так как итоговый балл нелинейно зависит от времени решения. Проще говоря,чем быстрее решена задача - тем ближе к максимуму будет балл.

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

Второе мое удивление было вызвано тем, что с единственной решенной задачей мой рейтинг стал равен 1295, что влечет попадание в первый дивизион.

То есть историю изменения ощущений можно выразить так
1. The Coding Phase. Чего уж говорить, облажался...
2. The System-Testing Phase. Хм, а не так уж и облажался вроде.
3. Осмысление сути бытия. Надо бы к следующему участию подготовиться получше :)