دانلود ترجمه مقاله بررسی تراکنش و انتقال پیام

• بخشی از ترجمه:

چکیده
ما بر این اعتقاد می باشیم که هر تراکنش به صورت مستقل می باشد، یعنی اینکه به انجام محاسبه بدون هیچ ارتباط مستقیمی با تراکنش های دیگر می پردازد. تراکنش به صورت غیر مستقیم ، البته از طریق ذخیره سازی و بازیابی داده در پایگاه داده، ارتباط بر قرار می کنند. به هر حال، این تنها روشی می باشد که تراکنش ها می توانند فعالیت یکدیگر را تحت تاثیر قرار دهند.
برای اطمینان از تراکنش به شکل دقیق، DBS (سرور پایگاه داده) می بایست به کنترل تمام روش هایی بپردازد که تراکنش انجام می گیرد. این بدین معنا می باشد که DBS (سرور پایگاه داده) می بایست به عنوان رابط هر فعالیت تراکنش بوده که می تواند تراکنش های دیگر را تحت تاثیر قرار دهد. در مدل ما، چنین عملیاتی تنها بر مبنای دسترسی به داده های مشترک می باشد. چون تراکنش دسترسی به داده های مشترک از طریق توزیع عملیات پایگاه داده به DBS (سرور پایگاه داده) دارد، ، DBS (سرور پایگاه داده) می تواند تا جایی که لازم است به کنترل چنین فعالیت هایی بپردازد.
در بسیاری از سیستم ها، تراکنش، امکان ارتباط را از طریق ارسال پیام هایی ایجاد می کند. ما امکان ارتباط چنین پیام هایی را در مدل مان مطرح می کنیم، به شرطی که چنین پیام هایی در پایگاه داده ذخیره گردند. تراکنش به ارسال و دریافت پیام از طریق نوشتن و خواندن جزییات اطلاعات، که آن پیام را شکل می دهد، می پردازد. این محدودیت بر روی ارتباط پیام، تنها در ارتباط بین پیام ها بکار گرفته می شود. دو یا چند مرحله ای که به نیابت از تراکنش مشابه به اجرا در می آید، می تواند آزادانه به تبادل پیام پرداخته، و نیاز نیست که این پیام ها در پایگاه داده ذخیره گردند. به طور کلی، تراکنش به صورت آزاد انجام می گیرد تا به کنترل موارد اجرایی داخلی با استفاده از مکانیسم های در دسترس بپردازد. تنها تعامل بین تراکنش مختلف توسط DBS (سرور پایگاه داده) تحت کنترل در می آید.
١.٢ قابلیت بازیابی
سیستم بازیابی باعث می شود که DBS (سرور پایگاه داده) به گونه ای عمل کند که پایگاه داده شامل تمام تاثیرات تراکنش انجام شده بوده و هیچ یک از تاثیرات مربوط به تراکنش انجام نشده باشد. اگر تراکنش هرگز متوقف نشوند، بازیابی نسبتا آسان می باشد. چون تمام تراکنش در نهایت به اجرا در می آیند، DBS (سرور پایگاه داده) به سادگی به اجرای عملیات پایگاه داده به محض ورود می پردازد. بنابراین به منظور درک بازیابی، می بایست در ابتدا نگاهی به پردازش موارد متوقف شده شده بیاندازیم.
زمانی که تراکنش بی نتیجه می ماند، DBS (سرور پایگاه داده) می بایست تاثیرش را متوقف کند. تاثیر تراکنش T به دو صورت می باشد: تاثیر بر روی داده؛ یعنی مقادیری که T در پایگاه داده ایجاد می کند؛ و تاثیر بر روی تراکنش دیگر، یعنی تراکنشی که مقادیر نوشته شده توسط T را می خواند. که هر دو می بایست پاک شوند.
DBS (سرور پایگاه داده) می بایست تاثیرات T را توسط بازیابی، برای هر قلم داده X که توسط T بروز می گردند حذف کند. مقدار X زمانی مد نظر قرار می گیرد که T هرگز به وقوع نپیوسته باشد. می توانیم بگوییم که DBS (سرور پایگاه داده) عملیات نوشتن T را خنثی می کند.
DBS (سرور پایگاه داده) می بایست تاثیرات T را با متوقف تراکنش انجام شده کنار بگذارد. بی نتیجه گذاشتن این تراکنش منجر به تحریک توقف شدن موارد دیگر می گردد، این پدیده به نام توقف آبشاری می باشد.

• بخشی از مقاله انگلیسی:

Abstract

We assume that each transaction is self-contained, meaning that it performs its computation without any direct communication with other transactions. Transactions do communicate indirectly, of course, by storing and retrieving data in the database. However, this is the only way they can affect each other’s execution. To ensure transaction atomicity, the DBS must control all of the ways that transactions interact. This means that the DBS must mediate each transaction’s operations that can affect other transactions. In our model, the only such operations are accesses to shared data. Since a transaction accesses shared data by issuing database operations to the DBS, the DBS can control all such actions, as required. In many systems, transactions are allowed to communicate by sending messages. We allow such message communication in our model, provided that those messages are stored in the database. A transaction sends or receives a message by writing or reading the data item that holds the message. This restriction on message communication only applies to messages between transactions. Two or more processes that are executing on behalf of the same transaction can freely exchange messages, and those messages need not be stored in the database. In general, a transaction is free to control its internal execution using any available mechanism. Only interactions between different transactions need to be controlled by the DBS. 1.2 RECOVERABILITY The recovery system should make the DBS behave as if the database contains all of the effects of committed transactions and none of the effects of uncommitted ones. If transactions never abort, recovery is rather easy. Since all transactions eventually commit, the DBS simply executes database operations as they arrive. So to understand recovery, one must first look at the processing of Aborts. When a transaction aborts, the DBS must wipe out its effects. The effects of a transaction Tare of two kinds: effects on data, that is, values that Twrote in the database; and effects on other transactions, namely, transactions that read values written by T. Both should be obliterated. The DBS should remove T’s effects by restoring, for each data item x updated by T, the value x would have had if T had never taken place. We say that the DBS undoes T’s Write operations. The DBS should remove T’s effects by aborting the affected transactions. For example, suppose the initial values of x and y are 1, and suppose transactions T, and T, issue operations that the DBS executes in the following order: Chatura Ranaweera, Harvir Bansal and Gordon McDougall Wilfrid Laurier University, Waterloo, Canada Transaction and message transfer (2013) 1.2 RECOVERABILITY 7 Write,(x, 2); Read,(%); Write2(y, 3). The subscript on each Read and Write denotes the transaction that issued it. Now, suppose T[ aborts. Then the DBS undoes Write^x, 2), restoring x to the value 1. Since T2 read the value of x written by T1; T2 must be aborted too, a cascading abort. So, the DBS undoes Write2(y, 3), restoring y to 1. Recall that by committing a transaction, the DBS guarantees that it will not subsequently abort the transaction. Given the possibility of cascading aborts, the DBS must be careful when it makes that guarantee. Even if a transaction T issues its Commit, the DBS may still need to abort T, because T may yet be involved in a cascading abort. This will happen if Tread a data item from some transaction that subsequently aborts. Therefore, T cannot commit until all transactions that wrote values read by Tare guaranteed not to abort, that is, are themselves committed.

دانلود رایگان مقاله انگلیسی

خرید ترجمه فارسی مقاله