Re: Transaction Management

Okay, I'll bite on this one.

Except Item 3, do you possibly mean 2PC (two phase commit) rather than 2PL, which I've never heard of?

Serialization and testing for it goes along with atomicity of transactions and their effects on others, and the definition of a logical unit of work (LUW). (This is in the books, by the way.)

Let's take atomicity first.
This is in pseudocode, not PL/SQL.

BEGIN ATM_CASH_WITHDRAW call validate_security

   invalid return reloop until n=? then goto eat_atm_card call acquire_balance

   requested_amount > available_amount then goto overdraw_schpiel call dispense_cash

   invalid return goto sorry_out_of_money_schpiel call post_transaction
call print_receipt
call you_wanna_anything_else?
  negative return
   goto thanks_for_letting_us_legally_rob_you   positive return
   goto how_may_we_further_clean_out_your_pockets? end

Atomicity means that if anything between the begin and end fails, the entire LUW must fail. The account must be checked, the cash must be dispensed, the receipt must be printed, the card must be ejected. Cash cannot be dispensed without a balance check and a debit. Cash (or deposits!!) should not be processed if a receipt cannot be or is not printed. If the machine is out of money, if the printer is out of paper, if the network is offline, if anything is wrong, the LUW is either done completely, or not at all.

Your secondary question is a lot shorter and easier to answer (believe it or not). Transaction atomicity and synchrony go hand in hand. All you need do is imagine husband and wife each with ATM cards to the same account.

Atomicity guarantees LUW integrity.
Synchrony means that two atomic transactions don't meddle with each other, and so subsequent transactions are enqueued, awaiting the success or failure of the first, since, of course, if hubby is running off to Tahiti with the secretary and is withdrawing a few grand, the bank would like that posted and deducted before the next transaction that is enqueued, namely the wife.

So transactions must be internally consistent, and either commit or rollback.
Similarly, transactions awaiting a shared resource (in this case, access to a bank account) must be enqueued and managed in order received as well as based upon the activity of the prior transaction affecting that resource.

such as

test balance = 0

   call print_list_of_divorce_lawyers
   goto print_sympathy_card
exit

"Sted Alana" <Sted_Alana_at_hotmail.com> wrote in message news:3cf8cb5a_1_at_news.iprimus.com.au...
> To All:
>
> 1) What is the purpose of testing for serializability of a transaction
> schedule?
>
> 2) Why is the relevance of view equivalence and conflict equivalence?
>
> 3) How to test if a transaction schedule is 2PL?
>
>
> Any suggestions appreciated.
>
> --
> N e w s N e t C u s t o m e r
> E - m a i l : sted.alana_at_hotmail.com
>
>
>
>
>
>
Received on Tue Jun 04 2002 - 17:13:55 CDT