Asp представление о транзакциях


Содержание

Управление транзакциями

Вопрос больше по архитектуре, чем по конкретной реализации.

Есть какие-то проверенные практики по управлению транзакциями в рамках определённого контекста выполнения (например, в пределах одного API-запроса)?

К тому, что ниже — я в курсе, что транзакции могут быть не только поверх конкретной базы под ORM, что они могут покрывать сразу несколько БД, могут включать в себя обращения к другим сервисам или очередям. Тут пока интересует самый простой случай, дабы совсем не запутаться.

Например, для стандартного сценария прохождения запроса на API:
1. Контроллер.
2. Сервис БЛ Сервис БЛ Сервис БЛ.
3. Репозиторий-1, Репозиторий-2.
4. ORM.

Ключевой пункт [2], где сервисы могут переиспользовать друг-друга в неожиданном порядке (т.е. они с точки зрения архитектуры все на одном уровне) и каждому из них может требоваться или не требоваться транзакция при общении с [3]->[4].

Из этого сходу напрашивается очевидное решение — регистрировать репозиторий/контекст-ORM со временем жизни ‘Scoped’, где-то до [2] заранее всегда открывать транзакцию при прохождении запроса вперёд и закрывать/откатывать при возврате результата. Например, в Invoke мидлвара, непосредственно перед вызовом метода контроллера.

Это удобное решение с точки зрения «один раз сделал и забыл», но, имхо, с точки зрения архитектуры кривоватое, т.к. сервисы теряют контроль над частью того функционала, который относится к их области ответственности (их ведь, да?). Т.е. если этот сервис вдруг будет переиспользован в другом API, то тот API тоже будет вынужден знать об особенностях применения транзакций этими сервисами.

Другая мысль — сервис БЛ сам открывает и закрывает транзакции, если ему это необходимо. Однако, в этом случае, если этот сервис вызывает какой-то другой сервис и ему тоже нужна транзакция, то нужно чтобы оба они работали в рамках одной транзакции, и появляется необходимость делать костыль с подсчётом количества открытий/закрытий транзакций и игнорированием лишних открытий и непоследних закрытий. Т.к. если транзакция жива в рамках всего запроса (или цепочки методов сервисов), то повторное её открытие приведёт к ошибке, так же как и преждевременное закрытие.

18.04.2020, 22:10

Управление транзакциями
Всем доброго времени суток. Пытаюсь добавить в проект управление транзакциями, выскакивает ошибка.

Управление транзакциями в С++
Нужно реализовать управление транзакциями в с++. А именно работу с 2мя структурами в файле.Вопросы.

Работа с транзакциями
Всем привет! Столкнулся с такой проблемкой: нужно обеспечить проверку данных с формы, и если.

Проблемы с распределёнными транзакциями
Если выполняю SELECT * FROM OPENROWSET(‘SQLOLEDB’,’BDC»sa»sa_passwd’, ‘SELECT * FROM.

Разобраться с транзакциями MySQL+dbExpress
Нужно разобраться как использовать транзакции, теорию почитал, теперь хотелось бы на практике.

20.04.2020, 10:01 2

Решение

Именно такое решение.

А вот это уже фигня) Используйте класс TransactionScope . Он допускает вложенные транзакции. Если сервису хочется открыть транзакцию, то он может это сделать со спокойной совестью. Ему не нужно знать о том, что транзакцию уже открыли. Провайдер ADO.NET тоже знает о TransactionScope (как и все ORM) и о возможности вложения транзакций.

Всё придумано до вас.

20.04.2020, 12:59 [ТС] 3

Пока не получилось разобраться, как прозрачно встроить его в проект.

Сейчас сделано на простом костыле — LinqToDB.Data.DataConnection регистрируется со временем жизни Scope (т.е. в рамках одного API-запроса), при создании этого объекта он автоматически открывает подключение к БД и удерживает его (это не я, он сам так себя ведёт).

Ну и в реализации DataConnection просто переопределил методы Begin/Commit/Rollback и считаю там количество открытий/закрытий, как описал выше.

Правда, это порождает некоторые неоднозначные ситуации и проблемы:
1. Транзакция открывается на уровне объекта ORM, сервис БЛ к этому объекту доступа не имеет, приходится в репозиториях (наследованием от базового репозитория) выставлять наружу свои методы Begin/Commit/Rollback . Кривовато выглядит.
2. Первый сервис открыл транзакцию, вложенный сервис тоже (по факту ничего не произошло), потом вложенный сервис откатил транзакцию (по факту ничего не произошло), а первый сервис её закоммитил. В итоге изменения вложенного сервиса тоже закоммитились. С другой стороны, это весьма странная ситуация с точки зрения БЛ, т.е. по идее, если вложенный сервис не смог отработать, он должен кинуть исключение и верхний сервис тоже откатит транзакцию.

Добавлено через 34 минуты
Как-то оно странно работает:
1. Сервис-1 создаёт TransactionScope (внутри using). Добавляет запись в таблицу. Вызывает метод Сервис-2.
2. Сервис-2 создаёт TransactionScope (внутри using). Добавляет запись в таблицу. Делает Complete .
3. Сервис-1 получает управление обратно. Далее (для теста) генерирует исключение. Т.е. он не доходит до вызова Complete .
4. Результат: обе записи добавлены в таблицу.

Добавлено через 9 минут
Не подскажете, как правильно использовать TransactionScope в рамках описанной в первом посте задачи и в сочетании с LinqToDb ?

Пока что, без TransactionScope , получилось проапгрейдить реализованный выше велосипед до отдельного сервиса с временем жизни Scoped , который имеет методы Begin/Commit/Rollback и знает про все коннекты уровня сессии. Это позволило убрать работу с транзакциями на уровне репозиториев. Теперь, если сервису БЛ нужна транзакция, он обращается к сервису транзакций, а тот уже разруливает вложенность обращений. Дополнительное удобство — т.к. нет необходимости оборачивать запуск транзакции в блок using , методы БЛ выглядят аккуратнее (без лишних отступов).

Как управлять транзакциями на уровне сервиса?

Были разработаны приложения .Net со следующей архитектурой: уровень представления (с использованием шаблона MVC с ASP.Net MVC 2), уровень обслуживания, уровень доступа к данным (с использованием шаблона репозитория над платформой Entity Framework).

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

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

например: мы предоставляем услугу отправки, которая имеет метод подтверждения, который получает следующие параметры: идентификатор доставки, флаг, указывающий, соответствует ли он новому клиенту или существующему, идентификатор клиента (в случае подтверждения отправки для существующего клиента) и имя клиента (в случае, если это для нового клиента). Если флаг установлен на «новый клиент», тогда сервисный уровень должен (а) создать клиента и (б) подтвердить отправку. Для (a) служба пересылки вызывает службу обслуживания клиентов (которая уже реализует проверки и логику, необходимые для создания нового клиента и хранения его в базе данных).

Кому следует зафиксировать изменения в этом сценарии?

  • Должно ли обслуживание клиентов делать это? он не может зафиксировать изменения после создания нового клиента, потому что что-то может пойти не так поздно позже в методе подтверждения отправки, но он должен зафиксировать свои изменения в случае, если он вызывается напрямую (в другом случае, предусмотренном для создания клиента).
  • Должен ли контроллер, вызывающий метод службы, делать это? но диспетчер не должен знать ничего о транзакциях, мы решили поместить всю транзакционную информацию в сервисный уровень.
  • Менеджер транзакций на уровне служб? Как его проектировать?, который называет его и когда?

Есть ли шаблон дизайна для этого, за которым мы должны следовать?


Oбзор моделей транзакций и стратегий их использования

Узнайте о трех моделях транзакций и стратегиях их использования

Серия контента:

Этот контент является частью # из серии # статей: Стратегии работы с транзакциями

Этот контент является частью серии: Стратегии работы с транзакциями

Следите за выходом новых статей этой серии.

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

Об этой серии

Транзакции позволяют повысить качество, целостность и согласованность данных, а также надежность приложения в целом. При этом реализация успешной схемы выполнения транзакций в приложениях Java представляет собой нетривиальную задачу, основная сложность которой заключается в проектировании, а не в написании кода. В этой новой серии Марк Ричардс предлагает свое руководство по дизайну эффективной стратегии управления транзакциями при решении различных задач – от создания простых приложений до реализации высокопроизводительных транзакционных систем.

Платформой Java поддерживаются следующие модели транзакций:

  • локальная модель;
  • программная модель;
  • декларативная модель.

Эти модели задают основные принципы поведения транзакций на платформе Java и то, как они должны реализовываться. При этом модели описывают только правила и семантику обработки транзакций, оставляя вопросы применения модели на усмотрение разработчика. Вам придется самостоятельно решать следующие вопросы: в каких случаях нужно использовать атрибут REQUIRED , а в каких MANDATORY ? Когда следует задавать директивы отката транзакций? Как сделать выбор между программной и декларативной моделями транзакций? Как оптимизировать транзакции для высокопроизводительных систем? Модели транзакций сами по себе не дают ответов на эти вопросы. Для этого вам следует либо разработать собственную стратегию использования транзакций, либо принять на вооружение одну из четырех основных стратегий, которые будут рассмотрены ниже.

В первой статье серии было продемонстрировано, что множество распространенных ошибок при использовании транзакций могут влиять на их поведение и, как следствие, ставить под угрозу целостность и согласованность ваших данных. Аналогичным образом, негативный эффект может произвести отсутствие эффективной (или любой) стратегии использования транзакций. Транзакционные модели, рассматриваемые в этой статье, играют роль строительного материала при разработке эффективной стратегии. Понимание этих моделей и различий между ними имеет колоссальное значение для понимания стратегий, которые их используют. После описания трех моделей мы перейдем к стратегиям использования, которые могут применяться практически во всех бизнес-приложениях, начиная от простых Web-приложений до крупных высокопроизводительных систем обработки транзакций. Более подробно эти стратегии будут рассмотрены в будущих статьях серии Стратегии работы с транзакциями.

Локальная модель транзакций

Локальная модель транзакций получила свое имя из-за того, что управление всеми транзакциями осуществляется менеджером ресурсов базы данных, а не контейнером или инфраструктурой, в которой выполняется ваше приложение. В этой модели вы сами управляете только соединениями, но не транзакциями. Как говорилось в статье Распространенные ошибки, вы не можете использовать локальную модель при выполнении изменений в базе данных через инфраструктуру объектно-реляционного отображения, например Hibernate, TopLink или Java Persistence API (JPA). Тем не менее вы можете применять эту модель при использовании объектов доступа к данным, инфраструктур JDBC и хранимых процедур.

Локальная транзакционная модель может использоваться двумя способами: либо путем программного управления соединениями, либо оставив это на усмотрение базы данных. Во втором случае необходимо установить свойство autoCommit JDBC-объекта Connection в true (это значение используется по умолчанию). Таким образом вы указываете системе управления базой данных (СУБД), что необходимо подтверждать транзакцию после выполнения каждой операции вставки, изменения или удаления записи, либо откатывать ее в случае ошибки. Этот подход иллюстрируется в листинге 1, в котором приводится фрагмент кода для вставки торгового приказа в таблицу TRADE .

Листинг 1. Пример использования локальных транзакций при выполнении одной операции изменения данных

Обратите внимание, что в листинге 1 свойство autoCommit устанавливается в значение true . Это является указанием СУБД, что локальная транзакция должна подтверждаться после выполнения каждого оператора БД. Этот подход работает отлично, если выполняется только одна операция в базе данных на каждую логическую единицу работы (LUW). Однако представьте, что метод processTrade() , показанный в листинге 1, также должен обновлять баланс счета в таблице ACCT , чтобы отразить сумму торгового приказа. В этом случае выполняются две независимые друг от друга операции, причем вставка записи в таблицу TRADE будет подтверждена до изменения записи в таблице ACCT . Если вторая операция завершится неудачно, то не будет возможности откатить результат первой, что приведет к рассогласованию данных.

В ответ на подобные ситуации был предложен второй подход – программное управление транзакциями. В этом случае свойство autoCommit объекта Connection должно равняться false , и вам придется самостоятельно подтверждать или откатывать транзакции. Пример приведен в листинге 2.

Листинг 2. Пример использования локальных транзакций при выполнении нескольких операций изменения данных

Обратите внимание, что в листинге 2 свойство autoCommit устанавливается в значение false , указывающее СУБД, что управление соединением будет осуществляться в коде, а не в базе данных. В этом случае необходимо вызывать метод commit() объекта Connection при успешном завершении операции. В случае же выброса исключения следует вызывать метод rollback() . Таким образом можно координировать выполнение двух операций внутри одной логической единицы работы.

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

Программная модель транзакций

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

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

Несмотря на то, что в Spring Framework и EJB 3.0 под программной моделью транзакций подразумевается одно и то же, ее реализация оказывается различной. Мы сначала рассмотрим реализацию модели в EJB 3.0, а затем выполним те же операции обновления базы данных при помощи Spring.

Программные транзакции в EJB 3.0

В EJB 3.0 вы должны запросить транзакцию у менеджера транзакций (другими словами, контейнера) через интерфейс JNDI (Java Naming and Directory Interface) по имени javax.transaction.UserTransaction . Получив ссылку на объект UserTransaction , вы можете вызвать метод begin() для начала новой транзакции, commit() – для подтверждения транзакции и rollback() — для отката транзакции в случае возникновения ошибки. При работе с этой моделью контейнер не будет автоматически подтверждать и откатывать транзакции, поэтому все действия по описанию поведения Java-метода, выполняющего изменения в базе данных, ложатся на плечи разработчика. Пример использования программной модели в EJB 3.0 и JPA приведен в листинге 3.

Листинг 3. Пример работы с программными транзакциями в EJB 3.0

При использовании программной модели транзакций внутри контейнера Java EE с компонентами сессии, не сохраняющими свое состояние, необходимо указать контейнеру, что используются программные транзакции. Для этого следует использовать аннотацию @TransactionManagement , задав BEAN в качестве типа транзакции. Если данная аннотация не используется, то контейнер будет полагать, что применяется декларативное управление транзакциями (тип CONTAINER , являющийся типом транзакций по умолчанию для EJB 3.0). Задавать тип транзакции не обязательно, если вы работаете на клиентском уровне вне контекста компонента сессии, не сохраняющего состояние.

Программные транзакции в Spring

Spring Framework поддерживает два способа реализации программной модели транзакций. Можно использовать либо класс TransactionTemplate , либо напрямую работать с менеджером транзакций платформы в Spring. Поскольку я не являюсь горячим сторонником анонимных внутренних классов и плохо читаемого кода, то мы рассмотрим только второй подход для иллюстрации программной модели транзакций в Spring.

В Spring присутствует, по крайней мере, девять платформенных менеджеров транзакций. Из них наиболее часто используются DataSourceTransactionManager , HibernateTransactionManager , JpaTransactionManager и JtaTransactionManager . Поскольку в наших примерах используется JPA, то конфигурация будет показана для класса JpaTransactionManager .

Для конфигурирования менеджера JpaTransactionManager в Spring необходимо определить объект класса org.springframework.orm.jpa.JpaTransactionManager в XML-контексте приложения и добавить в него ссылку на фабрику менеджеров сущностей JPA (JPA Entity Manager Factory). Затем в случае, если объект, содержащий логику вашего приложения, также управляется Spring, следует добавить в него ссылку на менеджер транзакций. Пример приведен в листинге 4.

Листинг 4. Описание менеджера транзакций JPA в Spring


Если же ваш прикладной класс не управляется Spring, то вы можете получить ссылку на менеджер транзакций, вызвав метод getBean() у класса, представляющего контекст Spring.

Теперь вы можете использовать платформенный менеджер для получения ссылки на транзакцию. После выполнения всех изменений можно вызвать метод commit() для ее подтверждения либо rollback() – для отката. Пример подобной работы приведен в листинге 5.

Листинг 5. Пример использования менеджера транзакций JPA в Spring

На примере, показанном в листинге 5, видно различие между Spring Framework и EJB 3.0. В Spring ссылка на транзакцию запрашивается путем вызова метода getTransaction() платформенного менеджера транзакций. После этого транзакция выполняется. Подробная информация о транзакции и ее поведении хранится в анонимном классе DefaultTransactionDefinition . Он содержит данные об имени транзакции, уровне изоляции, режиме распространения (он задается атрибутом транзакции) и значении тайм-аута, если таковой задан. В данном примере используются значения по умолчанию, т.е. именем транзакции является пустая строка, уровень изоляции определяется СУБД (как правило, это READ_COMMITTED ), режимом распространения является PROPAGATION_REQUIRED , а тайм-аут также зависит от СУБД. Кроме того, обратите внимание, что методы commit() и rollback() вызываются у менеджера транзакций, а не у самой транзакции, как в случае EJB.

Декларативная модель транзакций

Наиболее часто применяемой моделью транзакций на платформе Java является декларативная модель, также известная как модель транзакций, управляемых контейнером (Container Managed Transactions – CMT). При работе с этой моделью контейнер самостоятельно начинает, подтверждает и откатывает транзакции. Задачей разработчика является только описание поведения транзакций. Большинство ошибок, рассмотренных в первой статье серии, связаны с использованием именно декларативной модели.

Для описания поведения транзакций в Spring Framework и EJB 3.0 используются аннотации. В Spring аннотация называется @Transactional , а в EJB 3.0 – @TransactionAttribute . При использовании декларативной модели контейнер не будет автоматически откатывать транзакции при выбросе контролируемых исключений. Разработчику следует указать, когда и в каких именно случаях выброс таких исключений должен приводить к откату транзакции. В Spring Framework это делается при помощи свойства rollbackFor аннотации @Transactional . В EJB для этого служит метод setRollbackOnly() класса SessionContext .

Пример использования декларативной модели транзакций в EJB приведен в листинге 6.

Листинг 6. Пример использования декларативных транзакций в EJB 3.0

В листинге 7 иллюстрируется работа с декларативной моделью транзакций в Spring Framework.

Листинг 7. Пример использования декларативных транзакций в Spring

Атрибуты транзакций

Кроме директив отката необходимо задать атрибут транзакции, который определяет ее поведение. Платформа Java поддерживает шесть атрибутов транзакций вне зависимости от того, используете вы Spring Framework или EJB 3.0:

  • Required
  • Mandatory
  • RequiresNew
  • Supports
  • NotSupported
  • Never

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

Если к методу methodA() применяется атрибут Required и метод вызывается в области видимости ранее начатой транзакции, то именно она будет использоваться при выполнении метода. В противном случае метод methodA() начнет новую транзакцию. Если метод запустил новую транзакцию, то она должна завершиться (т.е. быть подтверждена или отменена) самим методом. Это наиболее часто используемый атрибут, являющийся атрибутом по умолчанию в EJB 3.0 и Spring. К сожалению, во многих ситуациях он применяется некорректно, что приводит к проблемам с согласованностью и целостностью данных. Использование этого атрибута будет обсуждаться более подробно в следующих статьях серии, посвященных стратегиям работы с транзакциями.

Если к методу methodA() применяется атрибут Mandatory и метод вызывается в области видимости ранее начатой транзакции, то она, как и ранее, будет использоваться при выполнении метода. Однако если метод вызывается вне контекста транзакции, то будет выброшено исключение типа TransactionRequiredException , сигнализирующее о том, что транзакция должна быть начата до вызова метода methodA() . Этот атрибут используется в стратегии клиентского дирижирования, рассматриваемой в следующем разделе статьи.

Атрибут RequiresNew представляет особый интерес. Более чем в половине случаев мне приходится констатировать, что разработчики неверно понимают или используют этот атрибут. Если он применяется к методу methodA() , то новая транзакция начинается (и, соответственно, должна быть закончена в данном методе) всегда, вне зависимости от того, был ли вызван метод в контексте существующей транзакции или нет. Это означает, что если methodA() был вызван в контексте некой транзакции (назовем ее Transaction1 ), то она будет прервана, и будет начата новая транзакция ( Transaction2 ). При завершении метода methodA() транзакция Transaction2 либо подтверждается, либо откатывается, после чего возобновляется выполнение Transaction1 . Такая схема работы очевидным образом нарушает принцип ACID (атомарность, согласованность, изолированность, стойкость), присущий транзакциям (особенно атомарность). Другими словами, операции изменения данных в БД более не содержатся внутри одной единицы работы. Если транзакцию Transaction1 придется откатить, то результаты Transaction2 все равно останутся подтвержденными. Если так, то зачем же нужен этот атрибут? Как объяснялось в первой статье, он должен использоваться только для операций, которые должны производиться вне зависимости от исхода первой транзакции ( Transaction1 ), например, для ведения аудита или журналирования.

Атрибут Supports является еще одним примером режима распространения, который большинство разработчиков либо не до конца понимают, либо не ценят. Если он применяется к методу methodA() , который вызывается в области видимости существующей транзакции, то метод будет выполнен внутри этой транзакции. Если же метод methodA() вызывается вне контекста транзакции, то транзакция не будет начата вовсе. Этот атрибут, как правило, используется для операций чтения данных из базы. Однако почему бы в этом случае не использовать атрибут NotSupported (описываемый в следующем абзаце)? Это будет означать, что метод будет выполняться вне контекста транзакции. Ответ достаточно прост. Если выполнять запрос внутри транзакции, то данные будут читаться из лога транзакций базы данных, т.е. будут видны только что сделанные изменения. Если же запрос выполняется вне транзакции, то ему будут доступны только неизмененные данные. Допустим, что вы добавляете новый торговый приказ в таблицу TRADE и сразу за этим, не заканчивая транзакцию, запрашиваете полный список всех приказов. В этом случае еще не подтвержденный приказ попадет в результаты запроса. Если бы использовался атрибут NotSupported , то в результаты попали бы только записи из таблицы, а не из лога транзакций, поэтому неподтвержденный заказ был бы не виден. Это далеко не всегда является нежелательным эффектом – все зависит от конкретной ситуации и бизнес-логики приложения.

Илон Маск рекомендует:  Что такое код swfgradient

Атрибут NotSupported означает, что метод не должен выполняться внутри транзакции, ни новой, ни уже существующей. Если этот атрибут указан для метода methodA() , вызванного в контексте транзакции, то она будет приостановлена до момента завершения метода. После выхода из метода выполнение транзакции будет возобновлено. Данный атрибут имеет смысл использовать в ограниченном числе случаев, причем, как правило, они связаны с вызовом хранимых процедур. Если хранимая процедура вызывается в контексте существующей транзакции, но при этом содержит строку BEGIN TRANS , или если базой данных является Sybase, работающая в несвязанном (unchained) режиме, то будет сгенерировано исключение, говорящее о том, что новая транзакция не может быть начата. Другими словами, вложенные транзакции не поддерживаются. Практически все контейнеры используют JTS (Java Transaction Service) в качестве реализации транзакций по умолчанию, и именно он (а не сама платформа Java) не поддерживает вложенные транзакции. Если у вас нет возможности изменить код хранимой процедуры, то можно использовать атрибут NotSupported для приостановки текущей транзакции, чтобы избежать исключения. При этом теряется свойство атомарности изменений, поскольку операции с базой данных более не являются частью одной LUW. Таким образом, использование этого атрибута имеет не только хорошие, но плохие стороны, но зато он может помочь вам быстро выбраться из сложной ситуации.

Наибольший интерес, вероятно, представляет атрибут Never . Он ведет себя практически так же, как NotSupported , за одним важным исключением: если метод, отмеченный данным атрибутом, вызывается в контексте транзакции, то выбрасывается исключение, сигнализирующее о том, что в момент вызова этого метода транзакция недопустима. Я смог придумать только одну ситуацию, при которой этот атрибут имеет смысл использовать: тестирование. Он позволяет легко и быстро проверить факт существования транзакции в момент вызова некоторого метода. Вызвав метод с атрибутом Never и получив в ответ исключение, вы можете быть точно уверены, что ранее была начата транзакция. В противном случае транзакции не существовало. Таким образом можно убедиться в надежной работе выбранной стратегии использования транзакций.

Стратегии использования транзакций

Модели транзакций, описанные в этой статье, являются основой стратегий использования транзакций, которые будут рассмотрены ниже. Перед тем как формировать собственную стратегию, важно досконально понимать различия между моделями. Основными стратегиями использования транзакций, которые могут применяться в большинстве бизнес-приложений, являются следующие:

  • стратегия клиентского дирижирования (client orchestration transaction strategy);
  • стратегия на основе интерфейсного слоя (API layer transaction strategy);
  • стратегия с высокой степенью параллелизма (High Concurrency transaction strategy);
  • высокопроизводительная стратегия (High-Speed Processing transaction strategy).

Далее я кратко представлю каждую из стратегий, а более подробно они будут рассмотрены в последующих статьях серии.

Стратегия клиентского дирижирования применяется в ситуациях, когда несколько клиентских обращений к серверу или модели составляют одну единицу работы. В качестве клиента может выступать инфраструктура Web-приложений, приложение-портал, настольное приложение либо, в некоторых случаях, даже система автоматизации деловых процедур (workflow) или компонент для управления бизнес-процессами (BPM). По сути, именно клиент определяет последовательность действий, необходимых для каждого конкретного запроса. Например, для отправки торгового приказа может быть необходимо сохранить его в базе данных, а затем обновить состояние счета клиента, отразив в нем сумму сделки. Если приложение предоставляет слишком «мелкозернистый» интерфейс, то приходится вызывать оба метода по отдельности. В этом случае транзакция должна определяться на клиентской стороне, чтобы гарантировать атомарность обработки запроса.

Стратегия на основе интерфейсного слоя применяется, когда приложение предоставляет меньшее количество методов, которые выступают в качестве основных точек доступа к серверной функциональности (при желании такие точки можно называть сервисами). При этом клиенты (в том числе клиенты Web-приложений и сервисов, клиенты систем обработки сообщений и даже настольные приложения) выполняют вызов только одного серверного метода для обработки запроса. Если применить эту стратегию к предыдущему примеру с отправкой торгового приказа, то следует создать один метод (назвав его, например, processTrade() ), который будет вызываться клиентами. Он должен содержать всю логику сохранения приказа и обновления состояния счета. Своим названием стратегия обязана тому факту, что, как правило, клиентские приложения получают доступ к серверной функциональности через интерфейсы. Данная стратегия является одной из наиболее часто используемых в настоящее время.

Стратегия с высокой степенью параллелизма является разновидностью описанной выше интерфейсной стратегии. Она используется в приложениях, поддерживающих долго выполняющиеся транзакции в интерфейсном слое (как правило, в целях повышения производительности или масштабируемости). Как следует из названия, эта стратегия, как правило, применяется в случаях, когда приложение должно параллельно обслуживать большое число клиентов. На платформе Java транзакции обходятся достаточно дорого. В зависимости от используемой базы данных, они могут приводить к блокировкам (в некоторых случаях даже взаимным блокировкам), захвату ресурсов и ухудшению пропускной способности приложения. Главной идеей, стоящей за этой стратегией, является сокращение контекста транзакций с целью минимизации блокировок, но при этом по-прежнему сохраняя свойство атомарности при обработке всех клиентских запросов. В некоторых случаях можно изменить логику приложения таким образом, чтобы применить данную стратегию использования транзакций.

Высокопроизводительная стратегия является, вероятно, наиболее экстремальной из всех возможных стратегий. Она применяется в случаях, когда необходимо добиться максимальной скорости обработки запросов (и, как следствие, пропускной способности), но при этом в какой-то мере сохранить атомарность выполнения транзакций. Данная стратегия подразумевает некоторый риск для целостности и согласованности данных, однако при правильной реализации она является наиболее быстрой из всех стратегий, возможных на платформе Java. В то же время она оказывается наиболее сложной и неудобной в реализации из всех четырех стратегий, упоминавшихся в этой статье.

Заключение

Как видите, разработка эффективной стратегии использования транзакций далеко не всегда представляет собой тривиальную задачу. Обеспечение целостности и согласованности данных требует серьезного обдумывания различных вариантов работы, используемых моделей, инфраструктур, конфигураций и методов. За долгие годы работы с приложениями, использующими транзакции, я понял, что хотя общее количество комбинаций различных моделей, методов и вариантов конфигурирования огромно, на практике имеет смысл применять лишь относительно небольшое число из них. Четыре разработанных мною стратегии использования транзакций, которые будут подробно рассматриваться в следующих статьях, должны охватывать большинство случаев, с которыми можно столкнуться при создании бизнес-ориентированных приложений на платформе Java. При этом необходимо оговориться: ни одна из стратегий не является своего рода «серебряной пулей» – простым и единственно верным решением проблемы. В некоторых случаях для реализации той или иной стратегии требуется рефакторинг исходного кода или дизайна приложения. В подобной ситуации вы просто должны спросить себя: «Насколько важно поддерживать целостность и согласованность моих данных?». Как правило, риски и возможные потери, связанные с искажением данных, перевешивают затраты, необходимые на рефакторинг приложения.

SQL Server: Управление транзакциями

Если вам нужно управлять операциями SQL Server на более детальном уровне, нужно тщательно продумать, как управлять связанными с транзакциями DMO-объектами (Dynamic Management Object). Все динамические административные представления (Dynamic Management View, DMV), относящиеся к категории «связанных с транзакциями», начинаются со строки «sys.dm_tran_».

В конечном итоге все инструкции, выполняемые в SQL Server , являются транзакционными. При выполнении даже одной инструкции SQL «под капотом» инициируется неявная транзакция. Она инициируется и автоматически завершается. При использовании явных команд BEGIN TRAN и COMMIT TRAN можно объединять их в явные транзакции, то есть наборы инструкций, которые должны выполняться все или ни одной.


В SQL Server реализованы различные уровни изоляции транзакций для гарантии таких свойств транзакций, как атомарность, согласованность, изоляция и долговечность (ACID). На практике это означает, что в них используются долго- и кратковременные блокировки для обеспечения транзактного доступа к общей базе данных и предотвращения того, чтобы транзакции не мешали друг другу.

Вообще говоря, стратегия и процесс исследования и управления транзакциями SQL Server можно ограничить несколькими ключевыми вопросами:

  • Какие транзакции активны и какие сеансы в них открыты? (административные представления со словами session_transactions, active_transactions)
  • Какие транзакции больше всего делают большую часть работы? (административные представления со словами database_transactions)
  • Какие транзакции создают проблемы с блокировками? (административные представления со словом locks).

Из всех этих вопросов чаще всего административные представления используются для исследования блокировок. Со временем должна повышаться активность в области исследования активности при использовании уровня изоляции моментального снимка. Этот вид изоляции впервые появился вSQL Server 2005. Изоляция моментального уровня устраняет возможность блокировки и взаимной блокировки за счет использования хранилища версий в базе данных tempdb для обеспечения параллелизма, а не создания блокировок объектов БД. Существует несколько динамических административных представлений для анализа этого уровня изоляции.

Мониторинг «долгоиграющих» транзакций

Перейдем к анализу сценариев. Если не указано иное, все эти сценарии работают в SQL Server 2005, 2008 и 2008 R2 и всем им требуется разрешение VIEW SERVER STATE. В сценарии используются два динамических представления. Первое, sys.dm_tran_database_transactions, описано в электронной документации по SQL Server так: «Возвращает сведения о транзакциях на уровне базы данных».

Второе, sys.dm_tran_session_transactions, «возвращает сведения о взаимосвязях связанных транзакций и сеансов».

Лаконичное описание sys.dm_tran_database_transactions больше скрывает, чем описывает настоящую полезность этого представления. Следующий сценарий содержит запрос, который показывает для каждого сеанса, какие базы данных используются в определенной транзакции, открытой этим сеансом, была ли эта транзакция переведена в состояние только для чтения в какой-то из баз данных (по умолчанию большинство транзакций доступны только для чтения), когда это случилось, сколько записей внесено в журнал и сколько байт были задействованы от имени этих записей в журнале:

SELECT st.session_id , DB_NAME(dt.database_id) AS database_name , CASE WHEN dt.database_transaction_begin_time IS NULL THEN ‘read-only’

ELSE ‘read-write’ END AS transaction_state , dt.database_transaction_begin_time AS read_write_start_time , dt.database_transaction_log_record_count , dt.database_transaction_log_bytes_usedFROM sys.dm_tran_session_transactions AS st INNER JOIN sys.dm_tran_database_transactions AS dt

Такие запросы представления sys.dm_tran_database_transactions очень полезны для наблюдения таких вещей, как:

  • Сеансов с открытыми транзакциями только для чтения (это особенно важно для «спящих» сеансов).
  • Сеансов, приводящих к неконтролируемому росту журнала транзакций.
  • Происходящего в «долгоиграющих» транзакциях (для операций без использования неполного протоколирования одна задействованная строка индекса создает примерно одну запись в журнале транзакций).

Обычная и краткосрочная блокировка

В нашем примере сценария используется динамическое представление sys.dm_tran_locks, предназначенное для работы с транзакциями и описанное в электронной документации так: «Возвращает сведения о ресурсах диспетчера блокировок, активного в данный момент. Каждая строка представляет текущий активный запрос диспетчеру блокировок о блокировке, которая была получена или находится в ожидании получения. Столбцы в результирующем наборе разделяются на две группы: ресурс и запрос. Группа ресурсов описывает ресурсы, на которые был выполнен запрос блокировки, а группа запросов описывает запрос блокировки».

Это административное представление полезно для выявления проблем с блокировками в экземпляре БД:

— Look at active Lock Manager resources for current database

DB_NAME(resource_database_id) AS [Database] , resource_type , resource_subtype , request_type , request_mode , resource_description , request_mode , request_owner_type
FROM sys.dm_tran_locksWHERE request_session_id > 50 AND resource_database_ > @@SPIDORDER BY request_session_id ;

— Look for blocking

SELECT tl.resource_type , tl.resource_database_ >

Первый запрос отображает перечень типов блокировок и их состояние по SPID, отобранных для одной базы данных, причем из списка исключены текущее подключение и системные идентификаторы SPID. Второй запрос предоставляет информацию обо всех блокировках в экземпляре. Заметьте, что второй запрос подключается к представлению sys.dm_os_waiting_tasks для получения данных о длительности ожидания процесса по причине блокировок, и из-за какого ресурса.

Обычно для того, чтобы «поймать» блокировку, приходится несколько раз выполнять каждый из этих запросов. Если вы обнаружите две инструкции изменения данных или запрос и изменение данных, которые «сплелись» в жесткой или даже взаимной блокировке, вам потребуется извлечь текст SQL -запросов, проанализировать их, выполнить на тестовой системе (с включенной трассировкой посредством Profiler) и решить проблему путем изменения запросов или добавления индексов.

Модели транзакций. Свойства. Способы завершения

Читайте также:

  1. II. Модели и типы данных.
  2. II. Общие способы защиты интеллектуальных прав.
  3. II. Способы защиты прав в суде
  4. IV. Способы проведения финальной части соревнований
  5. Акцессорные и неакцессорные способы обеспечения исполнения обязательств
  6. Алгоритмический язык моделирования дискретных систем во времени — МОДИС-В
  7. Аллювиальные отложения. Условия образования. Их разновидности. Инженерно- геологические свойства.
  8. Альтернативные способы рассмотрения споров (процедура медиации)
  9. Аналогия и моделирование
  10. Аналогия и моделирование.
  11. АНТРОПОЦЕНТРИЧЕСКИЕ МОДЕЛИ ВОСПИТАНИЯ
  12. АТРИБУТЫ АНАЛИЗИРУЕМОЙ МОДЕЛИ

Поддержка транзакций

Транзакция – действие или серия действий, выполняемых одним пользователем или прикладной программой, которые осуществляют доступ или из­менение содержимого базы данных.

«Транзакция является логической единицей работы, выполняемой в базе данных. И может быть представлена отдельной программой, являться частью алгоритма или даже отдельной командой (например, командой INSERT или UPDATE языка SQL) и включать произвольное количество операций, выполняемых в базе данных. С точки зрения базы данных, выполнение программы некоторого приложе­ния может расцениваться как серия транзакций, в промежутках между которыми выполняется некоторая обработка данных, осуществляемая вне среды базы данных. Для иллюстрации концепции транзакции рассмотрим два отношения:

Staff (Sno, FName, LName, Address, Tel__No, Position, Sex, DOB, Salary, NIN, Bno)

Property_for_Rent (Pno, Street, Area, City, Pcode, Type, Rooms, Rent, Ono, Sno, Bno)

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

Более сложная транзакция предназначена для удаления сведений о работнике, заданном его учетным номером x. В этом случае, помимо удаления соответствующего кортежа из отношения Staff, по­требуется найти все кортежи отношения Property_for_Rent, описывающие объекты недвижимости, за которые отвечал данный работник, после чего назначить их неко­торому другому работнику, личный номер которого будет иметь значение new_sno, Если все указанные изменения не будут внесены до конца, база данных окажется в несогласованном состоянии — за объект недвижимости будет отвечать несуществую­щий работник компании.

Любая транзакция всегда должна переводить базу данных из одного согласован­ного состояния в другое, хотя допускается, что согласованность состояния базы будет нарушаться в ходе выполнения транзакции.

Любая транзакция завершается одним из двух возможных способов. В случае ус­пешного завершения результаты транзакциификсируются (commit) в базе данных, и последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, онаотменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала дан­ной транзакции. Этот процесс называетсяоткатом (roll back) транзакции. Зафикси­рованная транзакция не может быть отменена. Если оказывается, что зафиксирован­ная транзакция была ошибочной, потребуется выполнить другую транзакцию, отме­няющую действия, выполненные первой транзакцией. В некоторых случаях эту транзакцию называюткомпенсирующей. Следует отметить, что отмененная транзак­ция может быть еще раз запущена позже и, в зависимости от причин предыдущего отказа, вполне успешно завершена и зафиксирована в базе данных.

Никакая СУБД не обладает внутренней возможностью установить, какие именно изменения должны быть восприняты как единое целое, образующее одну логическую транзакцию. Следовательно, должен существовать метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве язы­ков манипулирования данными для указания границ отдельных транзакций исполь­зуются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, вся выполняемая программа расценивается как единая транзакция. СУБД автоматически выполнит команду COMMIT при нор­мальном завершении этой программы. Аналогично, в случае ее аварийного заверше­ния в базе данных автоматически будет выполнена команда ROLLBACK.

Существуют некоторые свойства, которыми должна обладать любая из транзак­ций. Ниже представлены четыре основных свойства (ACID — аббревиатура, состав­ленная из первых букв их английских названий).


Атомарность. Это свойство типа «все или ничего». Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вовсе.

Согласованность. Каждая транзакция должна переводить базу данных из одного согласованного состояния в другое согласованное состояние.

Изолированность. Все транзакции выполняются независимо одна от дру­гой. Другими словами, промежуточные результаты незавершенной тран­закции не должны быть доступны другим транзакциям.

Продолжительность. Результаты успешно завершенной (зафиксированной) транзакции должны сохраняться в базе данных постоянно и не должны быть утеряны в результате последующих сбоев.

Улучшенные модели транзакций

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

– Простые типы данных — целые числа, десятичные числа, короткие сим­вольные строки и даты.

– Небольшая продолжительность транзакций, обычно не превышающая не­скольких минут или даже секунд.

– Рассмотрим различные средства разработки баз дан­ных, получивших в последнее время достаточно широкое распространение — инженерные (CAD), технологические (САМ) и программные (CASE). Все они имеют ряд общих характеристик, отличаю­щих их от традиционных приложений баз данных.

– Создаваемый проект может быть очень большим — вполне возможно, со­стоящим из миллионов частей, часто объединенных во множество взаимо­зависимых подсистем, представляющих собой отдельные проекты.

– Проект не является статическим объектом и постоянно эволюционирует. При внесении в проект изменения, его следствия часто распространяются на все имеющиеся в проекте подсистемы. Динамическая природа созда­ваемых проектов может означать, что некоторые действия просто не могут быть предусмотрены заранее, в самом начале работы.

– Выполняемые обновления могут иметь далеко идущие последствия, вызванные существующими сложными структурными взаимосвязями, функциональными зависимостями, допусками и т.д. Одно небольшое изменение вполне может оказать влияние на множество различных проектируемых элементов.

– Очень часто для отдельных компонентов проекта рассматривается множе­ство различных альтернативных вариантов, причем каждый раз требуется подготовить новую корректную версию всех его компонентов. Решение по­добных задач требует наличия средств контроля версий и инструментов управления выбираемой конфигурацией.

– В работу могут быть вовлечены сотни людей, работающих над нескольки­ми параллельными версиями одного крупного проекта. Тем не менее ко­нечный продукт должен быть согласованным и сбалансированным. Иногда такой стиль работы называют кооперативным проектированием. Коопера­ция требует четкого взаимодействия и полной согласованности всех разра­боток, выполняемых параллельно.

Некоторые из указанных выше особенностей являются причиной того, что вы­полняемые транзакции становятся чрезвычайно сложными, обрабатывающими мно­жество элементов данных и имеющими очень большую продолжительность — воз­можно, несколько часов, дней и даже месяцев. Подобные требования вынуждают пе­ресмотреть традиционные протоколы управления транзакциями с целью устранения следующих проблем.

– С учетом фактора времени,продолжительные транзакции более чувстви­тельны к отказам. Было бы совершенно неприемлемо отменить выполнение подобной транзакции с потенциальной потерей очень большого объема вы­полненной работы. Следовательно, чтобы минимизировать возможные по­тери, необходимо иметь средства для восстановления того состояния тран­закции, которое она имела незадолго до возникновения отказа.

– С учетом фактора времени, продолжительные транзакции могут получать доступ (например, устанавливать блокировки) к очень большому количест­ву элементов данных. Во избежание возможного взаимного влияния тран­закций, все эти элементы станут недоступными другим приложениям вплоть до завершения данной транзакции. Однако крайне нежелательно, чтобы существенный объем данных оставался недоступным на протяжении достаточно продолжительного периода времени, поскольку это отражается на уровне параллельности обработки в системе.

– Чем дольше выполняется транзакция, тем вероятнее возникновение ситуа­ции взаимной блокировки, когда в системе используется протокол, допус­кающий подобные ошибки. Было показано, что вероятность возникновения взаимной блокировки пропорциональна четвертой степени времени выпол­нения транзакции (Gray, 1981).

– Одним из способов организации кооперативной работы группы сотрудни­ков является предоставление им возможности совместно использовать тре­буемые элементы данных. Однако традиционные протоколы управления транзакциями существенно ограничивают возможности такой кооперации, соблюдая требования изоляции незавершенных транзакций друг от друга.

Модель вложенных транзакций

Модель вложенных транзакций была предложена Моссом (Moss) в 1981 г. В этой модели транзакция рассматривается как набор связанных подзадач, называемых субтранзакциями, каждая из которых также может состоять из произвольного коли­чества субтранзакций. В данном представлении полная транзакция представляет со­бой древовидную структуру или некоторую иерархию субтранзакций. В модели вло­женных транзакций присутствует транзакция верхнего уровня, содержащая некото­рое количество дочерних транзакций, каждая из которых, в свою очередь, может включать вложенные транзакции, и т.д. В исходном варианте, предложенном Моссом, только транзакциям листового уровня (субтранзакциям самого нижнего уровня вложения) разрешается выполнять операции в базе данных.

Для модели вложенных транзакций Моссом был предложен и протокол управле­ния параллельностью, построенный по принципу жесткой двухфазной блокировки. Субтранзакции родительской транзакции выполняются так, как если бы они были независимыми транзакциями. Субтранзакциям разрешается устанавливать блоки­ровку элемента, если некоторая другая транзакция, уже установившая блокировку, с которой конфликтует данная субтранзакция, является ее родительской. Когда суб­транзакция завершает работу, установленные ею блокировки наследуются родитель­ской транзакцией. При наследовании блокировки родитель получает более эксклю­зивный режим блокировки, если и дочерняя, и родительская транзакции устанавли­вали блокировку одного и того же элемента данных.

Ниже перечислены основные преимущества модели вложенных транзакций.

Модульность. Транзакция может быть разложена на произвольное количе­ство субтранзакций, что способствует повышению уровня параллельности обработки и расширяет возможности восстановления.

Создание дополнительного уровня детализации в механизмах управления параллельностью и восстановлением. Введение нового уровня субтранзак­ций, помимо уровня основных транзакций.

Достижение параллельности обработки в пределах транзакции. Субтран­закции могут выполняться в параллельном режиме.

Возможность управления восстановлением в пределах транзакции. Отме­ненные субтранзакции могут быть отброшены или проигнорированы без каких-либо побочных эффектов для других субтранзакций.

Эмуляция механизма вложенных транзакций с помощью точек сохранения

Точкойсохранения называется определенная точка в плоской транзакции, пред­ставляющая некоторое частично согласованное состояние, которая может быть ис­пользована как точка промежуточного рестарта транзакции в случае возникновения каких-либо проблем. Фактически, это одна из задач модели вложенных транзакций, состоящая в предоставлении некоторой единицы восстановления работы, более мел­кой, чем вся транзакция в целом. В процессе выполнения транзакции пользователь может организовать точку сохранения — например, с помощью оператора SAVE WORK. При его выполнении генерируется некоторый идентификатор, который пользователь впоследствии сможет применить для отката транзакции до данного, зафиксированно­го состояния — например, с помощью оператора ROLLBACK WORK идентификатор точки сохранений. Однако, в отличие от модели вложенных транзакций, при использовании точек сохранения не обеспечивается какая-либо из форм параллельности обработки в пределах транзакции.

Этот оператор не является стандартным оператором языка SQL и представляет собой лишь некоторую иллюстрацию.

Хроники

Концепция хроник (sagas), которая была введена Гарсия-Молином (Garsia-Molina) и Салемом (Salem) в 1987 г., построена на использовании понятия компенсирующих транзакций. Авторы определяют хронику как последовательность (плоских) тран­закций, которые могут чередоваться с прочими транзакциями. СУБД гарантирует, что либо все входящие в хронику транзакции будут успешно завершены, либо будут запущены компенсирующие транзакции, необходимые для устранения достигнутых частичных результатов. В отличие от метода вложенных транзакций, допускающего произвольный уровень вложения, метод хроник разрешает наличие единственного уровня вложения. Более того, для каждой выделенной субтранзакции должна суще­ствовать соответствующая компенсирующая транзакция, которая будет семантиче­ски аннулировать результаты, достигаемые с помощью данной субтранзакции. Таким образом, если имеется хроника, состоящая из последовательности п транзакций T1,T2. Тn с соответствующим набором компенсирующих транзакций С1, С2. Сn, то окончательный результат выполнения хроники будет определяться одной из сле­дующих последовательностей транзакций:

1) Т1,Т2. Тn — если вся транзакция была успешно завершена.

2) Ti, Tg. Т, Ci-1. Са, Ci — если выполнение транзакции Ti было прекращено.

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

По сравнению с обычными плоскими транзакциями, хроники нарушают требова­ния к изолированности отдельных транзакций, открывая промежуточные результаты своего выполнения другим, выполняющимся параллельно транзакциям еще до за­вершения своей работы. Применение хроник оказывается достаточно эффективным в тех случаях, когда входящие в нее субтранзакции относительно независимы и могут быть подготовлены необходимые компенсирующие транзакции. В некоторых случаях предварительное определение компенсирующей транзакции может оказаться затруд­нительным. В этом случае может потребоваться, чтобы СУБД провела некоторое взаимодействие с пользователем, который укажет подходящий случаю способ выпол­нения компенсации. В других случаях определение компенсирующей транзакции может оказаться вообще невозможным. Например, может оказаться невозможным подготовить компенсационную транзакцию для транзакции, которая получает вы­ручку из автоматического кассового аппарата.


Модель многоуровневых транзакций

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

Одним из вариантов модели открытых вложенных транзакций являетсямодельмногоуровневыхтранзакций, в которой дерево субтранзакций является сбалансиро­ванным (Weikum, 1991; Weikum and Schek, 1991). Узлы одного и того же уровня де­рева соответствуют операциям одного и того же уровня абстракции в СУБД. Ветви дерева представляют реализацию операции посредством последовательности опера­ций на следующем уровне глубины. Уровни n-уровневой транзакции обозначаются как l0, L1. Ln, где l0 — самый нижний уровень дерева, a Ln — корень дерева. Ме­тоды обработки обычных плоских транзакций гарантируют, что на самом нижнем уровне (L0) конфликты будут отсутствовать. Основная концепция модели многоуров­невых транзакций состоит в том, что две операции на уровне Li могут не конфликто­вать, даже если их реализации на следующем, более низком уровне Li-1 конфликту­ют. Используя преимущество знания информации о конфликтах на конкретном уровне, модель многоуровневых транзакций позволяет достичь более высокой степе­ни параллельности по сравнению с моделями обработки плоских транзакций.

Динамическая реструктуризация

В начале этого вопроса обсуждались некоторые особенности приложений под­держки выполнения различных проектов — например, неопределенная продолжи­тельность работы (от нескольких часов до месяцев), чередование с другими видами операций, неопределенность процесса обработки, не позволяющая предвидеть все ас­пекты работы с самого начала ее выполнения, и т.д. В обход ограничений, налагае­мых основными свойствами (ACID) плоских транзакций, были предложены две но­вые операции: разбиение транзакции (split_transaction) и объединение транзакций (join_transaction) (Pu et al., 1988). Принцип, положенный в основу операции разбие­ния транзакции, состоит в разделении активной транзакции на две упорядоченные транзакции и распределении между ними выполняемых действий и используемых ресурсов (например, заблокированных элементов данных). С этого момента вновь созданные транзакции могут независимо выполняться (возможно, даже под контро­лем разных пользователей) и обрабатываться так, как если бы они всегда были со­вершенно независимыми. Подобный подход позволяет сделать промежуточные ре­зультаты транзакции доступными другим транзакциям, причем с полным сохране­нием их семантики — другими словами, если исходная транзакция отвечала всем ACID-требованиям, то так же поведут себя и новые транзакции.

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

1. AWriteSet Ç BWriteSet Í BWriteLast. Это условие утверждает, что если обе транзакции, А и В, выполняют запись в один и тот же элемент данных, то операция’ записи транзакции В должна выполняться после операции записи транзакции А.

2. AReadSet Ç BWriteSet = Ø. Это условие утверждает, что транзакция А не мо­жет видеть никаких результатов выполнения транзакции В.

3. BReadSet Ç AWriteSet = ShareSet. Это условие утверждает, что транзакция В может видеть результаты выполнения транзакции А.

Приведенные выше условия гарантируют, что транзакция А в упорядоченном графике будет предшествовать транзакции В. Однако, если выполнение транзакции А будет прервано, выполнение транзакции В также необходимо будет отменить, по­скольку она использует данные, записанные транзакцией А. Если оба множества BWriteLast и ShareSet пусты, то транзакции А и В могут быть упорядочены в любой последовательности и работа их будет совершенно независимой.

Операция объединения транзакций выполняет обратные действия по отношению к операции разделения транзакций, сливая результаты работы двух или более неза­висимых транзакций так, как если бы эти транзакции всегда представляли собой единую транзакцию. Использование операций разделения транзакции, дополненных операциями объединения одной или больше вновь созданных транзакций, позволяет обмениваться ресурсами между определенными транзакциями, не делая эти ресурсы доступными другим транзакциям.

Основные достоинства метода динамической реструктуризации состоят в следующем.

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

Снижение уровня изолированности. Возможность освободить часть исполь­зовавшихся в транзакции ресурсов посредством фиксации уже выполнен­ной части ее работы.

Модели рабочих потоков

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

Рабочий поток представляет собой некоторый вид деятельности, предусматри­вающий координированное выполнение множества заданий, осуществляемых раз­личными субъектами обработки, которые могут представлять собой людей или не­которые программные комплексы (например, СУБД, прикладные программы или службы электронной почты

Перед любыми системами с рабочими потоками стоят две общие проблемы: опреде­ление рабочего потока и выполнение рабочего потока. Обе проблемы усложняются тем фактом, что во многих организациях одновременно используется несколько независи­мых компьютерных систем, предназначенных для автоматизации различных сторон общего процесса. Приведенные ниже определения выделяют ключевые элементы, ис­пользуемые при определении рабочего потока (Rusinkiewicz and Sheth, 1995).

Спецификация задания — структура выполнения каждого задания, опре­деляемая посредством предоставления набора обозримых извне состояний процесса и набора переходов между этими состояниями.

Требования по координации заданий — обычно задаются посредством указания зависимостей между процессами выполнения заданий и зависимостей между потоками данных, дополненных условиями завершения рабочего потока.

Требования к корректности выполнения — ограничения, накладываемые на показатели выполнения рабочего потока, с целью его соответствия тре­бованиям корректности в данном приложении. Сюда относятся требования по устойчивости к отказам, независимости и параллельности обработки, возможностям восстановления и т.д.

Процессам выполнения свойственна семантика открытой вложенности, допускаю­щая видимость промежуточных результатов процесса вне его границ и разрешающая различным компонентам фиксировать результаты своей работы в индивидуальном по­рядке. Компонентами могут быть другие субъекты обработки, характеризующиеся как семантикой открытой вложенности, так и семантикой закрытых вложенных транзак­ций, результаты функционирования которых будут видны всей системе только после полного завершения работы этого компонента. Следует отметить, что компоненты с се­мантикой закрытых вложенных транзакций могут состоять только из компонентов с семантикой того же типа. Некоторые из этих компонентов могут расцениваться как жизненно важные, и в случае отказа от их выполнения потребуется прекратить выпол­нение и их родительских компонентов. Кроме того, могут быть определены компенси­рующие и возможные (альтернативные) транзакции, речь о которых уже шла выше.

Дата добавления: 2015-05-09 ; Просмотров: 4449 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Asp представление о транзакциях

Транзакционная NTFS — (TxF) технология в Windows Vista и последующих операционных системах, позволяющая производить файловые операции на разделе с файловой системой NTFS при помощи транзакций, обеспечивая поддержку семантики атомарности, согласованности,… … Википедия

Программная транзакционная память — Для улучшения этой статьи желательно?: Проверить качество перевода с иностранного языка. В компьютерных технологиях, программная транзакционная память ( … Википедия

Распределенная файловая система — Это список файловых систем и сетевых протоколов, эмулирующих работу файловой системы, с небольшим описанием. Чтобы узнать более, вы можете пройти по соответствующей ссылке. Некоторые старые системы поддерживали только одну файловую систему,… … Википедия

Распределённая файловая система — Это список файловых систем и сетевых протоколов, эмулирующих работу файловой системы, с небольшим описанием. Чтобы узнать более, вы можете пройти по соответствующей ссылке. Некоторые старые системы поддерживали только одну файловую систему,… … Википедия

OLTP — (Online Transaction Processing), транзакционная система обработка транзакций в реальном времени. Способ организации БД, при котором система работает с небольшими по размерам транзакциями, но идущими большим потоком, и при этом клиенту… … Википедия

Транзакция — Не следует путать с трансакция. Транзакция (англ. transaction) в информатике, группа последовательных операций, которая представляет собой логическую единицу работы с данными. Транзакция может быть выполнена либо целиком и успешно,… … Википедия

Транзакция (информатика) — У этого термина существуют и другие значения, см. Транзакция (значения). Транзакция (англ. transaction) группа последовательных операций с базой данных, которая представляет собой логическую единицу работы с данными. Транзакция может… … Википедия

Список файловых систем — Это список файловых систем (ФС) и сетевых протоколов, эмулирующих работу файловой системы, с небольшим описанием. Чтобы узнать более, вы можете пройти по соответствующей ссылке. Некоторые старые системы поддерживали только одну файловую систему,… … Википедия

Распределенная ФС — Это список файловых систем и сетевых протоколов, эмулирующих работу файловой системы, с небольшим описанием. Чтобы узнать более, вы можете пройти по соответствующей ссылке. Некоторые старые системы поддерживали только одну файловую систему,… … Википедия

Распределенные ФС — Это список файловых систем и сетевых протоколов, эмулирующих работу файловой системы, с небольшим описанием. Чтобы узнать более, вы можете пройти по соответствующей ссылке. Некоторые старые системы поддерживали только одну файловую систему,… … Википедия

инструменты внутри UpdatePanel вызывая полные уведомления о транзакциях asp.net C #


У меня есть проблема с моей формой онлайн-заказа, я положил все мои DropDownLists и кнопки внутри UpdatePanel, но когда я выбираю что-то в DropDownList или при нажатии на кнопку целой страницы поста обратно . Пожалуйста, помогите мне! Это мой код: `

Я не могу увидеть код вашего выпадающего списка, я поймал себя на той же проблемой раз. Я установил выпадающий список AutoPostBack = True и определить метод в выбранном индексе изменился. Поэтому убедитесь, что вы не делать то же самое и загрузить полный код.

Транзактный анализ: кратко и по сути

Почти в каждой статье я упоминаю транзактный анализ. Это направление психотерапии за 5 лет стало для меня родным и близким. Результаты психотерапии при этом всегда превышают ожидания и радуют нас с Клиентами :-) Поэтому я с большим удовольствием представляю Вам статью о том, что такое транзактный анализ и как он работает.

Итак, в 60-е годы, один из последователей теории психоанализа Эрик Берн решил пойти собственным путём и выработал свою теорию личности. Его теория шла вразрез с классическим психоанализом только в том, что её можно было объяснить простыми словами большинству людей. И это делало терапевтические отношения более доверительными и эффективными для Вас.

В структуре статьи мы остановимся на двух аспектах:

  1. Структура личности.
  2. Как работает терапия

Структура личности

Психология начинается с теории личности, как театр с вешалки. В основе любой теории лежит структура личности человека.

Структура личности – это то, как данное направление видит человека и его психику.

Транзактный анализ изначально рассматривает любого человека как нормального, способного к изменениям и развитию. Слева вы видите «снеговичок». Это схематически изображенная структура личности по Эрику Берну.

В структуре есть 3 компонента, эго-состояния:

Каждое из них отражает эмоциональный опыт разных периодов жизни, воспоминания и образы важных людей либо же осознанность в настоящем времени.

Эго-состояние Родителя

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

Когда мы рождаемся на свет, мы еще ничего не знаем о мире. До того времени, как мы становимся способными осознавать себя и получать собственный опыт (до 3-х лет), источником знаний и опыта являются взрослые люди из ближайшего окружения. Они должны привить базовое чувство безопасности, обозначить для нас названия наших чувств, дать стартовые установки о том, «что такое хорошо и что такое плохо».

Эти знания и представления могут прививаться как сознательно, так и неосознанно. Кроме того, их можно транслировать как словесно, так и невербально – мимикой, жестами, даже настроением.

Наблюдение за важными взрослыми в детстве создает стойкий эмоциональный образ этих людей. Это называется интроект. У нас в подсознании «записаны» как на пленку масса интроектов (родители, опекуны, учителя, семейный врач, бабушки, дедушки…).

К чему эти три абзаца? К тому, что эго-состояние Родителя это и есть интроекты и тот опыт, который мы приняли от взрослых в раннем детстве.

Внутренний Родитель может быть в двух ипостасях:

  1. Контролирующий – это внутренний критик, который обесценивает, ругает и наказывает нас в нашем сознании. Когда в нас активен Контролирующий Родитель (КР), мы можем злиться на других, на их несовершенство. В этой структуре живут запреты и предписания, указания о том как необходимо и как категорически нельзя, а также стойкие представления о том, что нам будет за «неисполнение». КР – это конкретный взрослый человек, который контролировал, наказывал и зачастую не объяснял причин.
  2. Заботливый – это мягкий, дипломатичный, заботящийся Родитель. Тоже родом из детства и тоже на примере реального заботливого человека. Из этого эго-состояния мы отдыхаем, несмотря на загрузку на работе, едим когда голодны, поддерживаем себя в трудные времена. И также мы заботимся о других людях, находясь в ЗР. Тут «прописаны» рекомендации, пожелания, поощрения и педагогические наказания. Но при этом в Заботливом Родителе больше рационального.

Внутренний Родитель – очень важная наша часть, необходимая для того, чтобы с нами все было хорошо и для того, чтобы мы могли взаимодействовать с другими людьми. Однако нередко внутренний Родитель доминирует в структуре личности. И тогда человек может жить как будто не своей жизнью, находясь в конфликте между собой и своими интроектами.

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

Эго-состояние Ребенка

Как я писала ранее, мы приходим в мир «чистым листом». И уже со второго триместра беременности получаем первый эмоциональный опыт. В этой статье я не стану вдаваться в подробности, поверьте здесь на слово. Этот опыт маленькие дети получают постоянно, ведь им все в новинку.

Самый важный эмоциональный опыт для ребенка – это опыт общения с родителями. В реакции родителей на ребенка заложена его будущая картина мира. Неважно, что транслируется вербально родитель, важно с какими чувствами он это делает. Дети не имеют достаточно развитого рационального мышления, но отлично чувствуют разницу в эмоциональном отклике.

Эго-состояние Ребенка – это эмоционально значимый опыт на разных периодах детства. Раньше сюда включали опыт от рождения до 16 лет, сегодня же сюда относят и опыт о рождения.

Если в Родителе находятся запреты и предписания о том как надо и как нельзя, то в Ребенке живут чувства и потребности, а также эмоциональный ответ на них и на их удовлетворение. Тут находятся страхи, надежды, мечты, желания. В Родителе послания содержатся в виде интроектов, а в Ребенке живем мы сами в виде деток разного возраста в разных состояниях.

Из Детского эго-состояния мы можем вести себя как в похожей ситуации в прошлом. Например, в нас живо воспоминание о том, что бывает если заблудится и когда мы оказываемся в такой ситуации, будучи взрослыми, мы реагируем как маленький ребенок из той ситуации в прошлом.

Как и Родитель, Ребенок бывает двух «видов»:

  1. Адаптивный, в структуре которого выделяют еще и Бунтующего. Это Наш опыт из того времени, когда мы находились под влиянием реального Контролирующего Родителя (агрессивный отец, жестокая учительница). В этом состоянии много страха и подавления. Адаптивный Ребенок не спорит, позволяет возлагать на себя любую ответственность и боится. Главный страх в этом эго-состоянии – страх отвержения. Адаптивный Ребенок закладывается с очень ранних лет и укрепляется годами. Этим объясняется невозможность быстро вернуть нормальную самооценку. Кроме страха тут много вины, стыда, обиды.
  2. Бунтующий Ребенок – это Адаптивный, которому надоело. Ярким примером активного Бунтующего Ребенка является подросток-неформал. Кстати, если присмотреться то неформалы – это дети подавляющих и сверхконтролирующих родителей. Долгое время это отличники и «бабушкина радость», но в возрасте 14-16 лет они как с цепи срываются и вот мамина умница одевает кожаную мини-юбку и идет пить дешевое вино. В Бунтующем Ребенке живет много гнева, страха, и желания принадлежать. Этот протест обычно формируется в возрасте 3-х лет (я сам), подростковом периоде и в кризисные возрастные периоды (каждые 10 лет).
  3. Свободный Ребенок – это особенный Ребенок. Эго-состояние СР формируется в семьях, где ребенку можно все, что не опасно. Это творческая, чувствующая, жаждущая и очень живущая часть, из которой мы радуемся, веселимся и придумываем всякие классные идеи. СР – это спонтанная поездка в другой город, сочетание приятного с полезным, неожиданно хорошее настроение и креативный подход к идеям.

Находясь в активном Ребенке, мы, как и в случае с активным Родителем, не пребываем в контакте с реальностью. Мы реагируем как «там и тогда», как будто проживая «те» ситуации заново.

Про это эго-состояние я не буду писать много. Это состояние осознанности, лишенное Детских чувств и спонтанности и не подвластное Родительским установкам.


Во Взрослом мы осознаем себя здесь и сейчас, и реагируем из актуального возраста, адекватно ситуации. Во Взрослом практически нет эмоций. Тем не менее, наш Внутренний взрослый способен «слышать» и Родителя и Ребенка и принимать взвешенное решение.

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

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

Проблемы возникают тогда, когда доминирует Родительское или Детское эго-состояние, либо тогда, когда постоянно присутствует внутренний конфликт между ними.

Как работает терапия

Транзактный анализ основан на том, что мы взаимодействуем эго-состояниями. Причем, взаимодействуем как во внешнем мире – с другими людьми, так и во внутреннем – так называемый внутренний диалог.

Внутренний диалог очень часто имеет вид конфликта (Р-Д; Д-Р, Р-Р, Д-Д). Если этот конфликт долгий и интенсивный – мы столкнемся с очень тяжелыми чувствами, не сможем принять решение или принятое решение не приведет к положительному результату. Яркий пример – конфликт «хочу» и «надо».

Что происходит на консультации психолога?

На консультацию Вас может привести тяжелая или неоднозначная ситуация. Обычно запрос звучит как «помогите принять решение» или «не могу разобраться».

В кабинете мы с Вами разбираем конкретную ситуацию и отделяем именно Ваши желания и потребности от установок и назиданий Родительской части. Затем мы активируем Вашего взрослого, что позволяет принять актуальное решение.

Звучит просто и понятно, и после пары консультаций в кабинете Вы будете способны делать это самостоятельно. Но загвоздка в том, что без помощи психолога очень трудно отделить эго-состояния. Тогда есть соблазн назвать рассуждения своего Внутреннего Ребенка доводами Взрослого, или принять за Взрослого поучения Родителя.

Когда нужна психотерапия?

Люди редко приходят целенаправленно на психотерапию. Обычно это решение Вы принимаете тогда, когда осознаете, что неприятности и трудности происходят с Вами регулярно и по кругу. И что бы Вы не делали – круг остается кругом и все повторяется. Еще одним поводом для терапии может стать травмирующая ситуация любой давности.

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

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

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

Эта статья не призвана притащить всех на терапию. Но если после ее прочтения Вы что-то о себе поймете и будете готовы менять – я буду рада Вам у себя в кабинете и помогу Вам разобраться.

Если у Вас есть вопросы – пишите! С удовольствием отвечу.

Каков наилучший способ совершения автоматических транзакций с помощью Asp.Net MVC?

Мне становится неловко писать код во всем моем приложении MVC.

Я хотел бы сделать этот DRYer каким-то образом.

Я подумал о нескольких разных вариантах для этого.

  • Фильтр действий для декларативного обозначения определенных действий как транзакционных.
  • Переопределить OnActionExecuting в базовом классе контроллера и сделать все транзакции транзакциями за один снимок.

Есть ли одна из этих идей? Любую добычу, на которую я должен обратить внимание? Второй вариант кажется, что это может быть хорошим способом получить множество тупиков.

О да, я также использую StructureMap и пользовательский контроллер factory для ввода отпечатков в мои контроллеры, если кто-то знает о некоторых трюках для инъекций транзакций таким образом.

Для управления транзакциями вы можете использовать раздел «Порядок работы» . Основное преимущество шаблона работы — то, что вы можете сохранить стратегию транзакций на одном месте или несколько мест, когда у вас есть несколько стратегий. Самый простой интерфейс работы может быть:

Вы можете создавать различные реализации UnitOfWork для разных ORM или для хранимых процедур или на жестком кодированном sql. Вы можете начать транзакцию в начале запроса. Транзакция может быть размещена в конце запроса. Перед удалением вы можете обернуть фиксацию в блок try-catch с откатом в catch.

Стратегии запуска транзакций:

  • По запросу: одна транзакция используется для всего запроса, это самый лучший способ в большинстве случаев.
  • Несколько раз за запрос: транзакция за метод.
  • В разговоре: вы можете создать транзакцию по нескольким запросам процесса проверки корзины покупок.

Вы можете управлять своей транзакцией с помощью:

  • атрибуты
  • application_begin и метод endrequest в global.asax
  • HttpModule

При использовании StructureMap вы можете использовать гибридное кэширование как InstanceScope в единице конфигурации работы. Вы можете ввести блок работы в репозитории с помощью StructureMap.

Модели транзакций. Свойства. Способы завершения


Читайте также:

  1. II. Модели и типы данных.
  2. II. Общие способы защиты интеллектуальных прав.
  3. II. Способы защиты прав в суде
  4. IV. Способы проведения финальной части соревнований
  5. Акцессорные и неакцессорные способы обеспечения исполнения обязательств
  6. Алгоритмический язык моделирования дискретных систем во времени — МОДИС-В
  7. Аллювиальные отложения. Условия образования. Их разновидности. Инженерно- геологические свойства.
  8. Альтернативные способы рассмотрения споров (процедура медиации)
  9. Аналогия и моделирование
  10. Аналогия и моделирование.
  11. АНТРОПОЦЕНТРИЧЕСКИЕ МОДЕЛИ ВОСПИТАНИЯ
  12. АТРИБУТЫ АНАЛИЗИРУЕМОЙ МОДЕЛИ

Поддержка транзакций

Транзакция – действие или серия действий, выполняемых одним пользователем или прикладной программой, которые осуществляют доступ или из­менение содержимого базы данных.

«Транзакция является логической единицей работы, выполняемой в базе данных. И может быть представлена отдельной программой, являться частью алгоритма или даже отдельной командой (например, командой INSERT или UPDATE языка SQL) и включать произвольное количество операций, выполняемых в базе данных. С точки зрения базы данных, выполнение программы некоторого приложе­ния может расцениваться как серия транзакций, в промежутках между которыми выполняется некоторая обработка данных, осуществляемая вне среды базы данных. Для иллюстрации концепции транзакции рассмотрим два отношения:

Staff (Sno, FName, LName, Address, Tel__No, Position, Sex, DOB, Salary, NIN, Bno)

Property_for_Rent (Pno, Street, Area, City, Pcode, Type, Rooms, Rent, Ono, Sno, Bno)

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

Более сложная транзакция предназначена для удаления сведений о работнике, заданном его учетным номером x. В этом случае, помимо удаления соответствующего кортежа из отношения Staff, по­требуется найти все кортежи отношения Property_for_Rent, описывающие объекты недвижимости, за которые отвечал данный работник, после чего назначить их неко­торому другому работнику, личный номер которого будет иметь значение new_sno, Если все указанные изменения не будут внесены до конца, база данных окажется в несогласованном состоянии — за объект недвижимости будет отвечать несуществую­щий работник компании.

Любая транзакция всегда должна переводить базу данных из одного согласован­ного состояния в другое, хотя допускается, что согласованность состояния базы будет нарушаться в ходе выполнения транзакции.

Любая транзакция завершается одним из двух возможных способов. В случае ус­пешного завершения результаты транзакциификсируются (commit) в базе данных, и последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, онаотменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала дан­ной транзакции. Этот процесс называетсяоткатом (roll back) транзакции. Зафикси­рованная транзакция не может быть отменена. Если оказывается, что зафиксирован­ная транзакция была ошибочной, потребуется выполнить другую транзакцию, отме­няющую действия, выполненные первой транзакцией. В некоторых случаях эту транзакцию называюткомпенсирующей. Следует отметить, что отмененная транзак­ция может быть еще раз запущена позже и, в зависимости от причин предыдущего отказа, вполне успешно завершена и зафиксирована в базе данных.

Никакая СУБД не обладает внутренней возможностью установить, какие именно изменения должны быть восприняты как единое целое, образующее одну логическую транзакцию. Следовательно, должен существовать метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве язы­ков манипулирования данными для указания границ отдельных транзакций исполь­зуются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты). Если эти ограничители не были использованы, вся выполняемая программа расценивается как единая транзакция. СУБД автоматически выполнит команду COMMIT при нор­мальном завершении этой программы. Аналогично, в случае ее аварийного заверше­ния в базе данных автоматически будет выполнена команда ROLLBACK.

Существуют некоторые свойства, которыми должна обладать любая из транзак­ций. Ниже представлены четыре основных свойства (ACID — аббревиатура, состав­ленная из первых букв их английских названий).

Атомарность. Это свойство типа «все или ничего». Любая транзакция представляет собой неделимую единицу работы, которая может быть либо выполнена вся целиком, либо не выполнена вовсе.

Согласованность. Каждая транзакция должна переводить базу данных из одного согласованного состояния в другое согласованное состояние.

Изолированность. Все транзакции выполняются независимо одна от дру­гой. Другими словами, промежуточные результаты незавершенной тран­закции не должны быть доступны другим транзакциям.

Продолжительность. Результаты успешно завершенной (зафиксированной) транзакции должны сохраняться в базе данных постоянно и не должны быть утеряны в результате последующих сбоев.

Улучшенные модели транзакций

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

– Простые типы данных — целые числа, десятичные числа, короткие сим­вольные строки и даты.

– Небольшая продолжительность транзакций, обычно не превышающая не­скольких минут или даже секунд.

– Рассмотрим различные средства разработки баз дан­ных, получивших в последнее время достаточно широкое распространение — инженерные (CAD), технологические (САМ) и программные (CASE). Все они имеют ряд общих характеристик, отличаю­щих их от традиционных приложений баз данных.

– Создаваемый проект может быть очень большим — вполне возможно, со­стоящим из миллионов частей, часто объединенных во множество взаимо­зависимых подсистем, представляющих собой отдельные проекты.

– Проект не является статическим объектом и постоянно эволюционирует. При внесении в проект изменения, его следствия часто распространяются на все имеющиеся в проекте подсистемы. Динамическая природа созда­ваемых проектов может означать, что некоторые действия просто не могут быть предусмотрены заранее, в самом начале работы.

– Выполняемые обновления могут иметь далеко идущие последствия, вызванные существующими сложными структурными взаимосвязями, функциональными зависимостями, допусками и т.д. Одно небольшое изменение вполне может оказать влияние на множество различных проектируемых элементов.

– Очень часто для отдельных компонентов проекта рассматривается множе­ство различных альтернативных вариантов, причем каждый раз требуется подготовить новую корректную версию всех его компонентов. Решение по­добных задач требует наличия средств контроля версий и инструментов управления выбираемой конфигурацией.

– В работу могут быть вовлечены сотни людей, работающих над нескольки­ми параллельными версиями одного крупного проекта. Тем не менее ко­нечный продукт должен быть согласованным и сбалансированным. Иногда такой стиль работы называют кооперативным проектированием. Коопера­ция требует четкого взаимодействия и полной согласованности всех разра­боток, выполняемых параллельно.

Некоторые из указанных выше особенностей являются причиной того, что вы­полняемые транзакции становятся чрезвычайно сложными, обрабатывающими мно­жество элементов данных и имеющими очень большую продолжительность — воз­можно, несколько часов, дней и даже месяцев. Подобные требования вынуждают пе­ресмотреть традиционные протоколы управления транзакциями с целью устранения следующих проблем.

– С учетом фактора времени,продолжительные транзакции более чувстви­тельны к отказам. Было бы совершенно неприемлемо отменить выполнение подобной транзакции с потенциальной потерей очень большого объема вы­полненной работы. Следовательно, чтобы минимизировать возможные по­тери, необходимо иметь средства для восстановления того состояния тран­закции, которое она имела незадолго до возникновения отказа.

– С учетом фактора времени, продолжительные транзакции могут получать доступ (например, устанавливать блокировки) к очень большому количест­ву элементов данных. Во избежание возможного взаимного влияния тран­закций, все эти элементы станут недоступными другим приложениям вплоть до завершения данной транзакции. Однако крайне нежелательно, чтобы существенный объем данных оставался недоступным на протяжении достаточно продолжительного периода времени, поскольку это отражается на уровне параллельности обработки в системе.

– Чем дольше выполняется транзакция, тем вероятнее возникновение ситуа­ции взаимной блокировки, когда в системе используется протокол, допус­кающий подобные ошибки. Было показано, что вероятность возникновения взаимной блокировки пропорциональна четвертой степени времени выпол­нения транзакции (Gray, 1981).

– Одним из способов организации кооперативной работы группы сотрудни­ков является предоставление им возможности совместно использовать тре­буемые элементы данных. Однако традиционные протоколы управления транзакциями существенно ограничивают возможности такой кооперации, соблюдая требования изоляции незавершенных транзакций друг от друга.

Модель вложенных транзакций

Модель вложенных транзакций была предложена Моссом (Moss) в 1981 г. В этой модели транзакция рассматривается как набор связанных подзадач, называемых субтранзакциями, каждая из которых также может состоять из произвольного коли­чества субтранзакций. В данном представлении полная транзакция представляет со­бой древовидную структуру или некоторую иерархию субтранзакций. В модели вло­женных транзакций присутствует транзакция верхнего уровня, содержащая некото­рое количество дочерних транзакций, каждая из которых, в свою очередь, может включать вложенные транзакции, и т.д. В исходном варианте, предложенном Моссом, только транзакциям листового уровня (субтранзакциям самого нижнего уровня вложения) разрешается выполнять операции в базе данных.

Для модели вложенных транзакций Моссом был предложен и протокол управле­ния параллельностью, построенный по принципу жесткой двухфазной блокировки. Субтранзакции родительской транзакции выполняются так, как если бы они были независимыми транзакциями. Субтранзакциям разрешается устанавливать блоки­ровку элемента, если некоторая другая транзакция, уже установившая блокировку, с которой конфликтует данная субтранзакция, является ее родительской. Когда суб­транзакция завершает работу, установленные ею блокировки наследуются родитель­ской транзакцией. При наследовании блокировки родитель получает более эксклю­зивный режим блокировки, если и дочерняя, и родительская транзакции устанавли­вали блокировку одного и того же элемента данных.

Ниже перечислены основные преимущества модели вложенных транзакций.


Модульность. Транзакция может быть разложена на произвольное количе­ство субтранзакций, что способствует повышению уровня параллельности обработки и расширяет возможности восстановления.

Создание дополнительного уровня детализации в механизмах управления параллельностью и восстановлением. Введение нового уровня субтранзак­ций, помимо уровня основных транзакций.

Достижение параллельности обработки в пределах транзакции. Субтран­закции могут выполняться в параллельном режиме.

Возможность управления восстановлением в пределах транзакции. Отме­ненные субтранзакции могут быть отброшены или проигнорированы без каких-либо побочных эффектов для других субтранзакций.

Эмуляция механизма вложенных транзакций с помощью точек сохранения

Точкойсохранения называется определенная точка в плоской транзакции, пред­ставляющая некоторое частично согласованное состояние, которая может быть ис­пользована как точка промежуточного рестарта транзакции в случае возникновения каких-либо проблем. Фактически, это одна из задач модели вложенных транзакций, состоящая в предоставлении некоторой единицы восстановления работы, более мел­кой, чем вся транзакция в целом. В процессе выполнения транзакции пользователь может организовать точку сохранения — например, с помощью оператора SAVE WORK. При его выполнении генерируется некоторый идентификатор, который пользователь впоследствии сможет применить для отката транзакции до данного, зафиксированно­го состояния — например, с помощью оператора ROLLBACK WORK идентификатор точки сохранений. Однако, в отличие от модели вложенных транзакций, при использовании точек сохранения не обеспечивается какая-либо из форм параллельности обработки в пределах транзакции.

Этот оператор не является стандартным оператором языка SQL и представляет собой лишь некоторую иллюстрацию.

Хроники

Концепция хроник (sagas), которая была введена Гарсия-Молином (Garsia-Molina) и Салемом (Salem) в 1987 г., построена на использовании понятия компенсирующих транзакций. Авторы определяют хронику как последовательность (плоских) тран­закций, которые могут чередоваться с прочими транзакциями. СУБД гарантирует, что либо все входящие в хронику транзакции будут успешно завершены, либо будут запущены компенсирующие транзакции, необходимые для устранения достигнутых частичных результатов. В отличие от метода вложенных транзакций, допускающего произвольный уровень вложения, метод хроник разрешает наличие единственного уровня вложения. Более того, для каждой выделенной субтранзакции должна суще­ствовать соответствующая компенсирующая транзакция, которая будет семантиче­ски аннулировать результаты, достигаемые с помощью данной субтранзакции. Таким образом, если имеется хроника, состоящая из последовательности п транзакций T1,T2. Тn с соответствующим набором компенсирующих транзакций С1, С2. Сn, то окончательный результат выполнения хроники будет определяться одной из сле­дующих последовательностей транзакций:

1) Т1,Т2. Тn — если вся транзакция была успешно завершена.

2) Ti, Tg. Т, Ci-1. Са, Ci — если выполнение транзакции Ti было прекращено.

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

По сравнению с обычными плоскими транзакциями, хроники нарушают требова­ния к изолированности отдельных транзакций, открывая промежуточные результаты своего выполнения другим, выполняющимся параллельно транзакциям еще до за­вершения своей работы. Применение хроник оказывается достаточно эффективным в тех случаях, когда входящие в нее субтранзакции относительно независимы и могут быть подготовлены необходимые компенсирующие транзакции. В некоторых случаях предварительное определение компенсирующей транзакции может оказаться затруд­нительным. В этом случае может потребоваться, чтобы СУБД провела некоторое взаимодействие с пользователем, который укажет подходящий случаю способ выпол­нения компенсации. В других случаях определение компенсирующей транзакции может оказаться вообще невозможным. Например, может оказаться невозможным подготовить компенсационную транзакцию для транзакции, которая получает вы­ручку из автоматического кассового аппарата.

Модель многоуровневых транзакций

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

Одним из вариантов модели открытых вложенных транзакций являетсямодельмногоуровневыхтранзакций, в которой дерево субтранзакций является сбалансиро­ванным (Weikum, 1991; Weikum and Schek, 1991). Узлы одного и того же уровня де­рева соответствуют операциям одного и того же уровня абстракции в СУБД. Ветви дерева представляют реализацию операции посредством последовательности опера­ций на следующем уровне глубины. Уровни n-уровневой транзакции обозначаются как l0, L1. Ln, где l0 — самый нижний уровень дерева, a Ln — корень дерева. Ме­тоды обработки обычных плоских транзакций гарантируют, что на самом нижнем уровне (L0) конфликты будут отсутствовать. Основная концепция модели многоуров­невых транзакций состоит в том, что две операции на уровне Li могут не конфликто­вать, даже если их реализации на следующем, более низком уровне Li-1 конфликту­ют. Используя преимущество знания информации о конфликтах на конкретном уровне, модель многоуровневых транзакций позволяет достичь более высокой степе­ни параллельности по сравнению с моделями обработки плоских транзакций.

Динамическая реструктуризация

В начале этого вопроса обсуждались некоторые особенности приложений под­держки выполнения различных проектов — например, неопределенная продолжи­тельность работы (от нескольких часов до месяцев), чередование с другими видами операций, неопределенность процесса обработки, не позволяющая предвидеть все ас­пекты работы с самого начала ее выполнения, и т.д. В обход ограничений, налагае­мых основными свойствами (ACID) плоских транзакций, были предложены две но­вые операции: разбиение транзакции (split_transaction) и объединение транзакций (join_transaction) (Pu et al., 1988). Принцип, положенный в основу операции разбие­ния транзакции, состоит в разделении активной транзакции на две упорядоченные транзакции и распределении между ними выполняемых действий и используемых ресурсов (например, заблокированных элементов данных). С этого момента вновь созданные транзакции могут независимо выполняться (возможно, даже под контро­лем разных пользователей) и обрабатываться так, как если бы они всегда были со­вершенно независимыми. Подобный подход позволяет сделать промежуточные ре­зультаты транзакции доступными другим транзакциям, причем с полным сохране­нием их семантики — другими словами, если исходная транзакция отвечала всем ACID-требованиям, то так же поведут себя и новые транзакции.

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

1. AWriteSet Ç BWriteSet Í BWriteLast. Это условие утверждает, что если обе транзакции, А и В, выполняют запись в один и тот же элемент данных, то операция’ записи транзакции В должна выполняться после операции записи транзакции А.

2. AReadSet Ç BWriteSet = Ø. Это условие утверждает, что транзакция А не мо­жет видеть никаких результатов выполнения транзакции В.

3. BReadSet Ç AWriteSet = ShareSet. Это условие утверждает, что транзакция В может видеть результаты выполнения транзакции А.

Приведенные выше условия гарантируют, что транзакция А в упорядоченном графике будет предшествовать транзакции В. Однако, если выполнение транзакции А будет прервано, выполнение транзакции В также необходимо будет отменить, по­скольку она использует данные, записанные транзакцией А. Если оба множества BWriteLast и ShareSet пусты, то транзакции А и В могут быть упорядочены в любой последовательности и работа их будет совершенно независимой.

Операция объединения транзакций выполняет обратные действия по отношению к операции разделения транзакций, сливая результаты работы двух или более неза­висимых транзакций так, как если бы эти транзакции всегда представляли собой единую транзакцию. Использование операций разделения транзакции, дополненных операциями объединения одной или больше вновь созданных транзакций, позволяет обмениваться ресурсами между определенными транзакциями, не делая эти ресурсы доступными другим транзакциям.

Основные достоинства метода динамической реструктуризации состоят в следующем.

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

Снижение уровня изолированности. Возможность освободить часть исполь­зовавшихся в транзакции ресурсов посредством фиксации уже выполнен­ной части ее работы.

Модели рабочих потоков

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

Рабочий поток представляет собой некоторый вид деятельности, предусматри­вающий координированное выполнение множества заданий, осуществляемых раз­личными субъектами обработки, которые могут представлять собой людей или не­которые программные комплексы (например, СУБД, прикладные программы или службы электронной почты

Перед любыми системами с рабочими потоками стоят две общие проблемы: опреде­ление рабочего потока и выполнение рабочего потока. Обе проблемы усложняются тем фактом, что во многих организациях одновременно используется несколько независи­мых компьютерных систем, предназначенных для автоматизации различных сторон общего процесса. Приведенные ниже определения выделяют ключевые элементы, ис­пользуемые при определении рабочего потока (Rusinkiewicz and Sheth, 1995).

Спецификация задания — структура выполнения каждого задания, опре­деляемая посредством предоставления набора обозримых извне состояний процесса и набора переходов между этими состояниями.

Требования по координации заданий — обычно задаются посредством указания зависимостей между процессами выполнения заданий и зависимостей между потоками данных, дополненных условиями завершения рабочего потока.

Требования к корректности выполнения — ограничения, накладываемые на показатели выполнения рабочего потока, с целью его соответствия тре­бованиям корректности в данном приложении. Сюда относятся требования по устойчивости к отказам, независимости и параллельности обработки, возможностям восстановления и т.д.

Процессам выполнения свойственна семантика открытой вложенности, допускаю­щая видимость промежуточных результатов процесса вне его границ и разрешающая различным компонентам фиксировать результаты своей работы в индивидуальном по­рядке. Компонентами могут быть другие субъекты обработки, характеризующиеся как семантикой открытой вложенности, так и семантикой закрытых вложенных транзак­ций, результаты функционирования которых будут видны всей системе только после полного завершения работы этого компонента. Следует отметить, что компоненты с се­мантикой закрытых вложенных транзакций могут состоять только из компонентов с семантикой того же типа. Некоторые из этих компонентов могут расцениваться как жизненно важные, и в случае отказа от их выполнения потребуется прекратить выпол­нение и их родительских компонентов. Кроме того, могут быть определены компенси­рующие и возможные (альтернативные) транзакции, речь о которых уже шла выше.

Дата добавления: 2015-05-09 ; Просмотров: 4450 ; Нарушение авторских прав? ;

Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет

Илон Маск рекомендует:  CSS. 100 и 1 совет
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL