Проектирование и разработка подсистемы управления транзакциями для АСУД "ЕВФРАТ" - Программирование, компьютеры и кибернетика дипломная работа

Главная

Программирование, компьютеры и кибернетика
Проектирование и разработка подсистемы управления транзакциями для АСУД "ЕВФРАТ"

Механизмы управления транзакциями в СУБД. Обзор средств удаленного взаимодействия с объектами. Разработка подсистемы управления транзакциями. Практический анализ производительности подсистемы. Способы защиты пользователей от опасных и вредных факторов.


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


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

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Один из способов увеличения производительности вычислительных систем - это переход от одноядерной процессорной архитектуры к многоядерной. Многоядерные процессоры позволяют увеличить количество инструкций, выполняемое за единицу времени. Однако производительность так же будет зависеть от используемого приложения и его оптимизации для выполнения на многоядерном процессоре. Чтобы приложение могло одновременно задействовать несколько процессорных ядер, оно должно хорошо распараллеливаться, иначе, если программный код подразумевает только последовательное выполнение, пользы от многоядерности не будет.
С каждым годом в мире компьютерной индустрии возрастает значимость так называемого «промежуточного программного обеспечения». Существует множество продуктов этой категории, производимых крупными, средними и даже мелкими компаниями, специализирующимися на программном обеспечении. В настоящее время термин «промежуточное программное обеспечение» («middleware») относится к любому программному компоненту, который располагается между пользовательскими приложениями на персональных компьютерах и РСУБД или унаследованной системой, непосредственно управляющими необходимыми данными.
Управление транзакциями - один из важнейших аспектов при создании надежных распределенных систем, хотя в различных технологиях создания таких систем степень универсальности управления транзакциями может существенно варьироваться.
Распределенная система является совокупностью взаимодействующих объектов, в общем случае имеющих состояния. Важнейшим отличием распределенных (многозвенных) систем от классических клиент-серверных приложений является то, что при начале транзакции в принципе неизвестно, сколько объектов, состояние которых нужно сохранять или восстанавливать по обычным правилам транзакций, принимают в этой транзакции участие. Клиент, посылающий запрос серверному объекту, в общем случае не знает, какую цепочку вызовов (и к каким объектам) породит этот единственный запрос. О цепочке вызовов в целом не имеет представление ни один из участвующих в ней объектов.
На сегодняшний день к информационным системам предъявляются жесткие требования, как производительности, так и надежности. В связи с этим существует необходимость предотвращения рассогласования данных, порождаемого параллельной работой нескольких пользователей с одними и теми же данными. Кроме того, не менее важно, чтобы никакие отказы и сбои не порождали рассогласование данных информационной системы. На данный момент наиболее распространены механизмы контроля операций с данными информационной системы посредством транзакций, как операций записи данных, так и чтения.
2.1.1 Механизмы управления транзакциями в СУБД
Для обеспечения целостности базы данных в классических СУБД используется механизм транзакций. Все операции с базой данных осуществляются только от лица транзакций, чье выполнение контролируется специальным алгоритмом, гарантирующим сохранение целостности базы. Алгоритмы управления транзакциями регулируют порядок совместной работы нескольких транзакций и поэтому обычно называются протоколами управления транзакциями. Такие протоколы основываются на предположении, что каждая из управляемых ими транзакций обладает некоторым заданным набором свойств. Разные протоколы могут опираться на разные наборы свойств транзакций, но наиболее стандартным является так называемый набор свойств ACID:
· Atomicity (атомарность): определяет, что транзакция является наименьшим, неделимым блоком алгоритма изменения данных. Другими словами, любые части (подоперации) транзакции либо выполняются все, либо не выполняется ни одной такой части. Поскольку на самом деле невозможно одновременно и атомарно выполнить последовательность команд внутри транзакции, вводится понятие «отката» (rollback): если транзакцию не удаётся полностью завершить, результаты всех до сих пор произведённых действий должны быть отменены и система возвращается в исходное состояние;
· Consistency (непротиворечивость): по окончанию транзакция оставляет данные в непротиворечивом состоянии;
· Isolation (изоляция): во время выполнения транзакции другие процессы не должны видеть данные в промежуточном состоянии;
· Durability (постоянство): независимо от проблем на нижних уровнях (к примеру, обесточивание системы или сбои в оборудовании) изменения, сделанные успешно завершённой транзакцией, останутся сохранёнными после возвращения системы в работу.
Обязательным требованием, предъявляемым к любому протоколу управления транзакциями, является условие сохранения целостного состояния базы данных при совместном выполнении транзакций. Основным критерием определения сохранения целостности базы и, следовательно, корректности работы протокола является критерий сериализуемости получающихся расписаний[1].
Все протоколы управления транзакциями подразделяются на два класса: пессимистические и оптимистические.
Отличительной особенностью протоколов пессимистического класса является предотвращение возможности возникновения конфликтов. Основным методом для достижения этого является механизм блокировок. Этот метод предполагает, что для использования какого-либо ресурса транзакции необходимо сначала получить блокировку на этот ресурс. Обладание блокировкой на данный ресурс гарантирует невозможность конфликта с другими транзакциями, которые хотят использовать тот же ресурс. Транзакциям, которые потенциально могут вызвать появление конфликта с держателем блокировки на ресурс, блокировка просто не выдается. В таком случае эта транзакция встает в очередь на получение блокировки на этот ресурс и продолжает работу после получения этой блокировки.
Одним из наиболее широко распространенных пессимистических протоколов является «двухфазный протокол» (2PL)[2], согласно которому все операции блокирования ресурсов должны предшествовать всем операциям разблокирования. В классическом варианте этого протокола рассматриваются блокировки двух видов - на чтение и на изменение.
Серьезная проблема, которая может возникнуть при применении пессимистического протокола, - это так называемая проблема возникновения «тупиков» (deadlock). Тупик - это такая ситуация, при которой каждая транзакция из некоторого множества ожидает получения блокировки на элемент, который в данный момент времени заблокирован другой транзакцией из этого множества. Попавшие в ситуацию тупика транзакции самостоятельно покинуть его не в силах и могут ждать вечно. Для борьбы с тупиками используются специальные методы их обнаружения и разрешения.
Основная идея оптимистических протоколов - максимизировать объем выполняемой работы. Эти протоколы дают шанс работать всем транзакциям, но разрешают благополучно завершиться только тем из них, чье завершение не влечет нарушения целостности базы.
С точки зрения менеджера управления транзакций при использовании оптимистического протокола выполнение транзакции делится на три концептуальные фазы: чтение, проверка и запись. В течение фазы чтения транзакция работает параллельно с другими транзакциями без каких-либо ограничений, но все измененные данные записываются в личную рабочую память транзакции, а не в базу. Когда транзакция завершает свою работу менеджер инициирует фазу проверки транзакции на наличие конфликтов с другими транзакциями. Если проверка окончилась удачно (т. е. конфликтов не обнаружено), то сделанные транзакцией изменения переносятся в базу и становятся видимыми другим транзакциям. В противном случае, сама транзакция или конфликтующие с ней транзакции завершаются анормально, т.е. сделанные изменения забываются (поведение в этом случае может быть специфично для конкретного протокола).
По типу проверки оптимистические протоколы делятся на «вперед смотрящие»[3] (forward validation) и «назад смотрящие»[4] (backward validation). Различие состоит в выборе множества транзакций для проверки на наличие конфликтов при завершении некоторой транзакции. Протоколы из первой группы используют в качестве такого множества все еще не завершенные транзакции (и анормально завершают все те из них, которые конфликтуют с целевой транзакцией, либо саму транзакцию). А «назад смотрящие» проводят проверку по отношению ко всем нормально завершившимся транзакциям и в случае конфликта анормально завершают только целевую транзакцию.
Основным недостатком пессимистического подхода являются простои во время тупиков и растрата машинных ресурсов на их обнаружение и разрешение. Оптимистический подход бесполезно тратит машинные ресурсы на работу транзакций, которые позже будут анормально завершены из-за возникновения конфликтов, а также на работу на стадии проверки при завершении каждой транзакции. Экспериментальные результаты показывают, что в случае классических СУБД пессимистический подход обычно показывает лучшие результаты[5,6]. Поэтому в большинстве современных промышленных СУБД используются разновидности пессимистических протоколов.
В отличие от классических СУБД в системе реального времени с каждой транзакцией ассоциируется директивный срок, т.е. момент времени, до которого транзакция должна быть завершена. По типу директивных сроков СУБД реального времени можно разделить на три основные группы: с жесткими, крепкими и мягкими директивными сроками[7]. В системе с жесткими директивными сроками любая задержка эквивалентна катастрофе, а с крепкими и мягкими директивными сроками только понижает производительность системы. Различие последних состоит в том, что в системе с крепкими директивными сроками транзакция, пропустившая свой директивный срок, выкидывается из системы, а в системе с мягкими директивными сроками такая транзакция просто становится менее значимой, но все еще может быть с пользой завершена.
По достижении директивного срока в системах первого типа транзакция становится «вредной», т.е. имеет отрицательную полезность. Если же директивные сроки крепкие, то транзакция просто становится бесполезной, но не «вредной». А в системах с мягкими директивными сроками полезность транзакции начинает постепенно уменьшаться с увеличением времени опоздания.
Еще одним важным отличием от случая классических СУБД является использование других критериев производительности. В классических СУБД, производительность обычно измеряется как среднее число завершившихся транзакций в единицу времени, а в системе, работающей в реальном времени, на первый план выходят другие параметры - количество транзакций, пропустивших свои диpективные сроки, среднее опоздание транзакций и т. п. Производительность же обычно меряют при помощи величины, которая зависит от нескольких таких параметров.
Способы вычисления этих величин сильно отличаются для разных типов СУБД реального времени. Так, например, в системах с крепкими директивными сроками среднее время опоздания транзакций не играет никакой роли, в то время как в системах с мягкими директивными сроками этот параметр довольно полезен.
Отличие критериев производительности, используемых в базах данных реального времени, от тех, что используются в классических СУБД, является основной причиной далеко не лучшей производительности при применении в системах реального времени классических протоколов управления транзакциями. Это, очевидным образом, влечет необходимость использования в таких системах других протоколов, которые лучше справляются со специфическими требованиями систем реального времени.
Используемые в СУБД реального времени протоколы должны использовать приоритеты транзакций, основанные на их директивных сроках, при разрешении конфликтов, для того, чтобы гарантировать, что транзакция с большим приоритетом не будет задержана транзакцией с меньшим приоритетом. Это требование совершенно не учитывается в классических протоколах и это является одной из основных причин их неудовлетворительной производительности.
Наиболее известными пессимистическими протоколами для баз данных в системах реального времени являются модификации 2PL. Рассмотрим вкратце некоторые из них.
Основная идея первой модификации, называемой 2PL-HP (High Priority)[8] - разрешать все конфликты в пользу транзакций с большим приоритетом. Если ресурс, на который транзакция запрашивает блокировку, свободен, транзакция получает блокировку. Если он заблокирован, то возможны варианты:
· если запрашиваемая блокировка не конфликтует с уже существующими блокировками других транзакций на означенный ресурс, то она выдается, если приоритет транзакции выше, чем у всех транзакций, стоящих в очереди на блокировки этого ресурса;
· если транзакция имеет приоритет выше, чем у всех держателей блокировок на ресурс, то все они должны быть оборваны и транзакция получает блокировку;
· в остальных случаях транзакция становится в очередь на эту блокировку.
Протокол 2PL-HP гарантирует отсутствие тупиков.
Другая модификация - 2PL-WP (Wait Promote)[9] - основана на идее наследования приоритета. Когда первая транзакция с большим приоритетом запрашивает блокировку на какой-то ресурс, который в данный момент заблокирован второй транзакцией с меньшим приоритетом, то она встает в очередь (как в 2PL), при этом второй транзакции повышают приоритет до уровня приоритета первой. В результате вторая транзакция может быть выполнена быстрее, поскольку ей меньше придется простаивать дожидаясь других ресурсов, и, следовательно, приближается момент получения блокировки на означенный ресурс первой транзакцией. Однако, при применении этого метода (из-за рекурсивного повышения приоритетов) легко может возникнуть ситуация, когда большинство или даже все транзакции имеют одинаковый приоритет. В таком случае поведение этого протокола будет мало отличаться от поведения классического 2PL.
Большинство оптимистических протоколов, применяемых в СУБД реального времени, относятся к классу «вперед смотрящих». Для повышения производительности в СУБД реального времени возникающие между транзакциями конфликты должны разрешаться в пользу транзакций с большим приоритетом, а это невозможно при применении «назад смотрящих» оптимистических протоколов, поскольку в этом случае конфликты возникают с уже завершившимися транзакциями. Рассмотрим примеры оптимистических протоколов для систем реального времени.
Протокол OPT-SACRIFICE[10] является адаптированным к СУБД реального времени вариантом протокола OCC-FV (Optimistic Concurrency Control with Forward Validation). Согласно OPT-SACRIFICE транзакция, достигшая фазы проверки, обрывается, если хотя бы одна из конфликтующих с ней транзакций имеет больший приоритет. Иначе транзакция благополучно завершается, а все конфликтующие с ней транзакции завершаются анормально. Таким образом, проверяемая транзакция, которая уже почти завершилась, приносит себя в жертву ради еще работающей транзакции с большим приоритетом. Этот протокол имеет ряд слабых мест. Обрыв транзакции в пользу более высокоприоритетной означает, что работа по ее выполнению была выполнена напрасно и ресурсы, потраченные на это, были потрачены зря. Кроме того, не гарантирован факт нормального завершения более высокоприоритетной транзакции, таким образом жертва может оказаться напрасной.
Согласно протоколу OPT-WAIT[10], также принадлежащему к классу «вперед смотрящих» протоколов, транзакция, достигнув фазы проверки и обнаружив множество конфликтующих с ней транзакций, ведет себя следующим образом:
· если ее приоритет выше, чем у всех конфликтующих с ней транзакций, то она завершается нормально, а все конфликтующие - анормально;
· иначе транзакция не обрывается немедленно, а ждет завершения тех из конфликтующих, чей приоритет выше ее собственного, и затем завершается нормально только в том случае, если все эти конфликтующие завершились анормально.
Этот протокол, в отличие от OPT-SACRIFICE, не отличается обилием бесполезных рестартов, так как все они совершаются по необходимости. Однако он также имеет ряд слабых мест. Эффект блокирования, возникающий в результате задержки транзакции на стадии проверки (вместо ее непосредственного завершения или обрыва), приводит к консервированию ресурсов, тем самым приводя к тем проблемам, с которыми сталкиваются пессимистические протоколы в системах реального времени. Кроме этого, даже в случае успешного завершения задержанной транзакции, это может вызвать анормальное завершение множества более низкоприоритетных транзакций (как работающих, так и задержанных). Более того, число анормальных завершений может возрасти за счет тех низкоприоритетных транзакций, которые конфликтовали с задержанной транзакцией, но не конфликтовали с более высокоприоритетными. Это число может сильно расти с ростом времени задержки нашей транзакции.
Традиционно протоколы управления транзакциями различаются по двум критериям: время обнаружения конфликтов и способ их обнаружения. Согласно этим критериям пессимистические и оптимистические протоколы представляют собой две крайности. Пессимистические протоколы пытаются обнаружить конфликты сразу, еще до их возникновения, и разрешают их, используя механизм блокирования. Оптимистические протоколы занимаются обнаружением конфликтов при завершении транзакции и разрешают их, перезапуская часть конфликтующих транзакций. Оба способа разрешения конфликтов имеют свои недостатки. Блокирование приводит к консервированию ресурсов, а рестарты вызывают их растрату. В системах реального времени протокол управления транзакциями должен работать с большим количеством анормально завершающихся транзакций. И, если для оптимистических протоколов это знакомая ситуация, то для пессимистических протоколов рестарты являются новым ограничением.
Слабым местом пессимистического протокола являются также простои транзакций, в ожидании получения блокировки на какой-либо ресурс. Такие простои повышают вероятность пропуска директивного срока. При этом транзакция, которая держала блокировку на нужный ресурс, также может пропустить свой директивный срок - из-за того, что он слишком близок или из-за необходимости ждать получения блокировок на другие ресурсы. Тем самым возможно, что все транзакции не успеют завершиться к своим директивным срокам.
Оптимистические протоколы не блокируют ресурсы и не вызывают простоев транзакций, что несомненно является плюсом для систем реального времени. Обратная сторона медали - растрата ресурсов на параллельную работу конфликтующих транзакций, из которых только часть в принципе может завершиться. Кроме того необходимо отметить, что фаза проверки может быть довольно трудоемкой и это особенно заметно, если сами транзакции очень коротки.
Сравнительный анализ этих двух подходов для модели простых транзакций в системах управления базами данных реального времени с мягкими и крепкими директивными сроками, с ограниченным числом ресурсов и неограниченным, показывает, что в большинстве ситуаций оптимистический подход превосходит пессимистический. Однако, в связи с огромным количеством систем реального времени со специфическими требованиями не существует лучшего протокола для всех случаев, и бывают ситуации, когда пессимистический протокол показывает лучшие результаты.
В идеале транзакции разных пользователей должны выполняться так, чтобы создавалась иллюзия, что пользователь текущей транзакции -- единственный. В этом заключается реализация свойства Isolation из набора ACID, которая не обязательна, но в случае пренебрежения ею может повлечь появление проблем. В реальности, по соображениям производительности и для выполнения некоторых специальных задач, СУБД предоставляют различные уровни изоляции транзакций: неподтвержденное или грязное чтение (Read Uncommited), подтвержденное чтение (Read Commited), повторяемое чтение (Repeatable Read, Snapshot) и самый высокий - упорядоченный уровень (Serializable). Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы их поддерживать. В СУБД уровень изоляции транзакций можно выбрать как для всех транзакций сразу, так и для некоторой конкретной транзакции. Подробнее об уровнях изоляции речь пойдет позже.
Полноценная реализация уровней изоляции и свойств ACID представляет из себя нетривиальную задачу. Обработка поступающих данных приводит к большому количеству маленьких изменений, включая обновление как самих таблиц, так и индексов. Эти изменения потенциально могут потерпеть неудачу, например если закончилось место на диске, операция занимает слишком много времени (timeout) и т. д. Система должна в случае неудачи корректно вернуть базу данных в состояние до транзакции.
Первые коммерческие СУБД (к примеру, IBM DB2), пользовались исключительно механизмом блокировок доступа к данным для реализации свойств ACID. Но большое количество блокировок приводит к существенному уменьшению производительности. Есть два популярных семейства решений этой проблемы, которые снижают количество блокировок: журнализация изменений (Write Ahead Logging, WAL) и механизм теневых страниц (Shadow Paging). В обоих случаях, блокировки должны быть расставлены на всю информацию, которая обновляется. В зависимости от уровня изоляции и имплементации, блокировки записи также расставляются на информацию, которая была прочитана транзакцией.
При «упреждающей журнализации», используемой в Sybase и MS SQL Server до версии 2005, записи о некоторой операции над базой данных попадают на энергонезависимый носитель (обычно в этой роли выступает жесткий диск) раньше, чем в базу вносятся изменения, произведенные этой операцией. Это позволяет СУБД вернуться в рабочее состояние после неожиданного отказа системы.
Альтернативной техникой, используемой для восстановления в случае сбоев, является механизм «теневых страниц». Основное отличие систем, использующих теневые страницы, от систем, где для восстановления используется только журнал, заключается в том, что последние записывают изменения, внесенные в страницу базы данных в то же место, где располагалась предыдущая версия данных. При использовании же теневых страниц, измененная версия страницы данных записывается на другое место диска. В случае сбоя можно восстановить базу данных на основе старой (теневой) версии страницы и журнала. Как видно, идея, стоящая за теневым механизмом, проста и легко поддается реализации. Однако по ряду причин техника восстановления на основе теневых страниц, несмотря на всю свою простоту, считается хуже, чем восстановление с использованием упреждающей журнализации.
Дальнейшее развитие СУБД привело к появлению так называемых «безблокировочных» технологий. Идея контроля за параллельным доступом с помощью временных меток (Timestamp-Based Concurrency Control) была развита и привела к появлению многоверсионной архитектуры MVCC. Управление конкурентным доступом с помощью многоверсионности (MVCC - MultiVersion Concurrency Control) заключается в предоставлении каждому пользователю так называемого «снимка» БД, обладающего тем свойством, что вносимые данным пользователем изменения в БД невидимы другим пользователям до момента фиксации транзакции. Этот способ управления позволяет добиться того, что пишущие транзакции не блокируют читающих, а читающие транзакции не блокируют пишущих. Эти технологии не нуждаются ни в журнализации изменений, ни в теневых страницах. Архитектура, реализованная в Oracle версии 7.х и выше, записывает старые версии страниц в специальный «сегмент отката», но они все ещё доступны для чтения. Если транзакция при чтении попадает на страницу, временная метка которой новее начала чтения, данные берутся из сегмента отката (то есть используется «старая» версия). Для поддержки такой работы ведётся журнал транзакций, но в отличие от «упреждающей журнализации», он не содержит данных. Работа с ним состоит из трёх логических шагов:
1. Записать намерение произвести некоторые операции;
2. Выполнить задание, копируя оригиналы изменяемых страниц в сегмент отката;
3. Записать, что всё сделано без ошибок.
Журнал транзакций в сочетании с сегментом отката (область, в которой хранится копия всех изменяемых в ходе транзакции данных) гарантирует целостность данных. В случае сбоя запускается процедура восстановления, которая просматривает отдельные его записи следующим образом:
· Если повреждена запись, то сбой произошёл во время проставления отметки в журнале. Значит, ничего важного не потерялось, игнорируем эту ошибку;
· Если все записи помечены как успешно выполненные, то сбой произошёл между транзакциями, здесь также нет потерь;
· Если в журнале есть незавершённая транзакция, то сбой произошёл во время записи на диск. В этом случае мы восстанавливаем старую версию данных из сегмента отката.
Firebird вообще не имеет ни журнала изменений, ни сегмента отката, а реализует MVCC, записывая новые версии строк прямо в активное пространство данных. Также поступает MS SQL 2005. Теоретически это даёт максимальную эффективность при параллельной работе с данными, но ценой является необходимость «сборки мусора», то есть удаления старых и уже не нужных версий строк.
2.1.2 Системы управления распределенными транзакциями
Существует два главных аспекта управления транзакциями, а именно: управление восстановлением и управление параллельностью обработки. Оба этих аспекта имеют расширенную трактовку в среде распределенных систем. Чтобы разъяснить особенности этой расширенной трактовки, сначала необходимо ввести новое понятие «агент». В распределенной системе отдельная транзакция может включать в себя выполнение кода на многих узлах[11]. Поэтому говорят, что каждая транзакция содержит несколько агентов, где под агентом подразумевается процесс, который выполняется для данной транзакции на отдельном узле. Система должна знать, что два агента являются элементами одной и той же транзакции, например два агента, которые являются частями одной и той же транзакции, очевидно, не должны оказаться в состоянии взаимной блокировки.
Теперь обратимся непосредственно к управлению восстановлением. Чтобы обеспечить атомарность транзакции (принцип «все или ничего») в распределенной среде, система должна гарантировать, что все множество относящихся к данной транзакции агентов или зафиксировало свои результаты, или выполнило откат. Такого результата можно достичь с помощью «двухфазного протокола фиксации» транзакции.
Что касается управления параллельностью, то оно в большинстве распределенных систем базируется на механизме блокирования, точно так же, как и в не распределенных системах. В нескольких более новых коммерческих продуктах была реализована многовариантная блокировка данных, однако на практике обычное блокирование еще, кажется, по-прежнему остается тем методом, который выбирается в большинстве систем.
Распределенные объектные системы обеспечивают средства размещения и взаимодействия объектов в распределенной среде. Объекты идентифицируются именами или сервисами, а также поддерживаемыми ими интерфейсами. Реализация объекта и платформа, на которой он выполняется, прозрачны для клиента.
Во многих организациях используется более чем одна система баз данных, и требуется возможность выполнять транзакции, пересекающие границы этих систем. Многие системы баз данных требуют наличия отдельного процесса операционной системы для каждого подключенного пользователя. Для приложений с сотнями пользователей не хватает мощности даже самых крупных компьютеров. Кроме всего прочего, установление соединения с базой данных часто происходит медленно. Если много пользователей часто подключается и отключается, производительность системы серьезно деградирует. Эти проблемы решаются в большинстве систем, управляющих распределенными транзакциями, следующим образом:
· Обеспечивается одновременная связь с набором различных систем баз данных;
· Поддерживается двухфазный протокол фиксации, гарантирующий завершение транзакций над несколькими базами данных;
· Пользовательские запросы обрабатываются с использованием легковесных нитей - потоков (threads) операционной системы, а не полновесных процессов. Это позволяет использовать возможности SMP-систем (Symmetric MultiProcessor), таких как Sun Enterprise, Digital Alpha и Compaq Proliant;
· Поддерживается постоянный пул подключений к базам данных, и эти подключения разделяются между пользователями. В большинстве приложений каждый пользователь реально обращается к базе данных только часть общего времени. Часто сотни «одновременно работающих» пользователей могут быть эффективно обслужены за счет наличия одной трети или даже одной десятой от числа подключений к базе данных, требуемых для прямого доступа;
· Долговременное сохранение разделяемых подключений к базе данных существенно уменьшает трафик подключений;
· Обеспечивается балансировка нагрузки путем планирования использования разделяемых ресурсов и направления запросов к наименее загруженным серверам. Возможно, также обнаруживать и обрабатывать ситуации, когда сервер или другой ресурс выходит из строя и нуждается в перезапуске;
· Запросы обрабатываются асинхронно с распределением нескольких запросов к одному и тому же серверу между разными подключениями к базе данных (так называемый «конвейерный» параллелизм);
· Запросы распределяются между несколькими серверами баз данных (так называемый «развернутый» параллелизм).
Для координации операций разделенных и распределенных приложений поддерживается одноранговая связь с другими мониторами обработки транзакций.
2.1.3 Управление транзакциями в среде .NET
Все или ничего -- в этом главный смысл транзакции. При сохранении нескольких записей либо все они должны быть записаны, либо вся операция должна быть отменена. Если происходит один единственный сбой при внесении одной записи, то все, что было выполнено к этому моменту в пределах данной транзакции, откатывается. Транзакции широко используются при работе с базами данных, но классы из пространства имен System.Transaction библиотеки классов .NET Framework позволяют выполнять транзакции с изменчивыми или находящимися в памяти объектами, такими как списки объектов[12]. Если список поддерживает транзакции, объект добавляется или удаляется и транзакция завершается неудачей, то все операции со списком автоматически отменяются. Запись в списки, находящиеся в памяти может выполняться в той же транзакции, что и запись в базу данных.
Наиболее распространено применение транзакций при внесении и обновлении информации в базе
Проектирование и разработка подсистемы управления транзакциями для АСУД "ЕВФРАТ" дипломная работа. Программирование, компьютеры и кибернетика.
Сочинения 19 Века
Реферат по теме Жанровое своеобразие шекспировских пьес
Дипломная Работа На Тему Раскол Русской Церкви В Середине Xvii Века
Реферат: Операции, влияющие на величину валюты баланса
Доклад по теме Трифонов Ю.В.
Курсовая Работа На Тему Защита Трудовых Прав Работников По Законодательству Российской Федерации И Республики Беларусь
Легочная Реанимация Реферат
Нужно Ли Сравнивать Себя С Другими Сочинение
Мен Өз Саламның Маманымын Эссе
Дипломная работа: Анализ денежных потоков ООО "Виктория-Гранд"
Дипломная работа по теме Робота з діаграмами в Microsoft Excel. Приготування в офісі та організація презентацій
Подпись Для Контрольных Работ По Математике
Сочинение Егэ Историческая Память
Шум Диссертация
Контрольная Работа Кинематика Ответы
Реферат: Роль социологических знаний в образовании и деятельности инженера
Курсовая работа по теме SWOT-анализ компании 'Эксперт Северо-Запад'
Контрольная работа по теме Ответственность за нарушение правил перевозки грузов и пассажиров автомобильным транспортом, претензии, иски
Варианты Контрольных Работ 1 Четверть 6 Класс
Курсовая работа по теме Электрические сети нефтяных месторождений Южного Васюгана ОАО 'Томскнефть'
Аудит розвитку персоналу - Бухгалтерский учет и аудит реферат
Система управления качеством продукции - Менеджмент и трудовые отношения дипломная работа
Культура Древнего Рима - Культура и искусство контрольная работа