Прозрачность параллельности

Пример распределенной транзакции

Рассмотрим выполнение транзакции Т, выполняющей распечатку имен всего пер­сонала компании, при использовании схемы фрагментации, определенной раннее в виде фрагментов S1, S2, S21, S22 и S23. Транзакция будет включать три субтранзак­ции T_S3, T_S5 и T_S7, представленные агентами 3,5 и 7 соответственно. Ка­ждая из субтранзакций печатает имена работников локального отделения компании. График распределенной транзакции показан в таблице. Обратите внимание на естественную параллельность, свойственную системе, - каждая из субтранзакций выполняется параллельно с остальными.

Время	Транзакция Тs3	Транзакция Тs5	Транзакция Тs7
t1	begin_transaction	begin_transaction	begin_transaction
t2	read(fname,lname)	read(fname,lname)	read(fname,lname)
t3	print(fname,lname)	print(fname,lname)	print(fname,lname)
t4	end_transaction	end_transaction	end_transaction

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

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

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

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

Дата добавления: 2014-01-20