Autonomous transaction

Autonomous TransactionIndian PostgreSQL User Group Meetup

Author: Kumar Rajeev Rastogi

Email Id: [email protected]

Cell No: +91-8971367787

Linked-Lin: in.linkedin.com/pub/rajeev-rastogi-krr/23/189/b35/

mailto:[email protected]

http://in.linkedin.com/pub/rajeev-rastogi-krr/23/189/b35/







Contents

• Background

• Why Autonomous Transaction

• About Autonomous Transaction

• Autonomous Transaction Use-cases

• Autonomous Transaction by other DBs

• Conclusion

BackgroundTransactions are real world entities that can be expressed in the form of text,numbers or both to be processed by a database management system. They shouldmake sense as actions against the database and they must be performed as agroup.

For example a request to transfer X amount from user A’s account to user B’saccount is a simple transaction, where debit from A’s account and credit to B’saccount should be performed as a group i.e. either both should be successful orboth should fail.

Other jargons related to transactions are:

1. Transaction Properties

2. Transaction isolation level

3. Sub-transaction

4. Prepare Transaction

Background: Transaction Properties

Transactions have the following four standard properties, usually referred to by theacronym ACID:

• Atomicity: All changes to data are performed as if they are a single operation. Thatis, all the changes are performed, or none of them are.

• Consistency: Data is in a consistent state when a transaction starts and when itends.

• Isolation: The intermediate state of a transaction is invisible to other transactions.As a result, transactions that run concurrently appear to be serialized.

• Durability: After a transaction successfully completes, changes to data persist andare not undone, even in the event of a system failure..

Background: Transaction Isolation level

The isolation level of a transaction determines what data the transaction can seewhen other transactions are running concurrently. Following are the supportedisolation level in PostgreSQL:

• Read-Committed: A statement can only see rows committed before it began. Thisis the default behaviour.

• Repeatable Read: All statements of the current transaction can only see rowscommitted before the first query or data-modification statement was executed inthis transaction

• Serializable: All statements of the current transaction can only see rowscommitted before the first query or data-modification statement was executed inthis transaction. If a pattern of reads and writes among concurrent serializabletransactions would create a situation which could not have occurred for any serial(one-at-a-time) execution of those transactions, one of them will be rolled backwith a serialization_failure error

Background: Sub-TransactionSub-transaction, as the name suggest is part of main transaction, which is used inorder to take decision on intermediate operation performed inside maintransactions. This is mainly used for below purposes:

• Savepoint: If within a main transaction, you sometime required to rollback somepart of transaction, then we can define a save-point at a point till where rollbackneeds to be done. Once a save-point is defined and any operation done with-inthat a new nested transaction called sub-transaction gets started and maintransaction gets pushed to the stack. Once user issues the command to ROLLBACKSAVEPOINT, subtransaction gets rollbacked without effecting the main transactionand corresponding changes done to database. Also main transaction get poppedup to continue the further operation.

• Procedure with exception: If there is any procedure with exception handlingdefined with-in that means there is failure chance during the execution ofprocedure. So in such a sub-transaction gets under which all procedure relatedoperations are performed and if the failure happens, then this sub-transaction getsrollbacked without effecting the operation done before procedure call.

There may be multiple level of nested sub-transaction, so once a sub-transactionrollbacks, it rollbacks all the intermediate sub-transactions also.

Background: Prepare TransactionPREPARE TRANSACTION prepares the current transaction for two-phase commit.After this command, the transaction is no longer associated with the currentsession; instead, its state is fully stored on disk, and there is a very high probabilitythat it can be committed successfully, even if a database crash occurs before thecommit is requested.

Each prepare transaction is given a name, which can be used later to commitor rollback the transactions.

Contents

• Background





• Conclusion

Why Autonomous Transaction

Already so many transaction jargons,

Why do we need one more?

Why Autonomous Transaction

Current form of transaction (called main transaction) in PostgreSQL uses the fullcontext of transaction i.e. it has control on whole transaction life span and hasvisibility to all changes in current transaction.

So it is not possible to commit some part of transaction without effectingthe other part of transaction.

Hence a feature called “Autonomous Transaction” is required to address theabove mentioned issue.

Contents

• Background





• Conclusion

About Autonomous TransactionAn autonomous transaction has its own COMMIT and ROLLBACK scope to ensure thatits outcome does not effect the caller’s uncommitted changes. Additionally, theCOMMITs and ROLLBACK in the calling transaction should not effect the changes thatwere finalized on the completion of autonomous transaction itself.

Also calling transaction is suspended until the called transactionreturns control. You can suspend the calling transaction, perform SQL operations andCOMMIT or ROLLBACK them in autonomous transaction, and then resume the callingtransaction.

Autonomous Transaction have the following characteristics:

The autonomous transaction does not see uncommitted changes made by themain transaction and does not share locks or resources with main transaction.

Changes in an autonomous transactions are visible to other transactions uponcommit of the autonomous transactions. Thus , users can access the updatedinformation without having to wait for the main transaction to commit.

Autonomous transactions can start other autonomous transaction. There are nolimit, other than resource limits, on how many levels of autonomous transactioncan be started.

About Autonomous Transaction Contd…

Following figures show how control flows from main transactions (MT) toautonomous transaction (AT):

Prcoedure proc1

emp integer

Begin

emp = 10

insert …

select … proc2()

Delete …

commit;

End;

Prcoedure proc2

autonomous tx…

dept int

Begin

dept = 20

update …

commit;

End;

MT Begins

MT Ends

MT Suspends

AT begins

AT Ends

MT resumes

Contents

• Background





• Conclusion

Autonomous Transaction Use-casesAutonomous transaction is useful for many scenarios, some of the top use-cases areas below:

Error Logging

Auditing

Autonomous Transaction Use-cases: Error Logging

One of the very classic use-cases of autonomous transaction is “Error Logging”.

Say a procedure is defined, which does some operation on the database andincase of any failure it maintains the failure information in a separate relation. Butbecause of current transaction behavior, whole data will be roll-backed and henceerror information will be also lost, which might have been required for future analysis.

In order to solve this issue, we can use autonomous transaction as shownbelow:

CREATE OR REPLACE function operation(err_msg IN VARCHAR) returns void AS $$

BEGIN

INSERT INTO at_test(id, description) VALUES (998, ‘Description for 998’);

INSERT INTO at_test(id, description) VALUES (999, NULL);

EXCEPTION

WHEN OTHER THEN

PRAGMA AUTONOMOUS TRANSACTION;

INSERT INTO error_logs(id, timestamp, err_msg) VALUES(nextval(‘errno’),timenow(), err_msg);

COMMIT;

RAISE not_null_violation;

END;

$$ LANGUAGE plpgsql;

Autonomous Transaction Use-cases: Error Logging Contd…

Schema used in example are: Table to store actual data having NOT NULL constraint:

CREATE TABLE at_test(id int, description varchar(100) NOT NULL);

Error logging table to store error information:CREATE TABLE error_logs(id int, log_time timestamp, err_msg varchar(100));

Sequence to maintain error counting:CREATE SEQUENCE errno;

So above procedure operation is defined in such a way that if insertion to at_testfails, then it should log the failure information in the error_logs table along witherror number and timestamp at which error happened.

Now lets see below for execution of procedure:

postgres=# select operation(‘failure’);ERROR: not null violationSTATEMENT: select operation(‘failure’);ERROR: not_null_violation

Autonomous Transaction Use-cases: Error Logging Contd…

*After execution of procedure:Postgres=# select * from error_logs;id | log_time | err_msg----+---------------------+---------

5 | 2014-01-17 19:57:11 | error

postgres=# select * from at_test;id | decsription----+-------------(0 rows)

As we can see from procedure definition, on failure, it catches the exception andstarts the autonomous transaction to log error and then it commits only operationdone in autonomous transaction and rest of operation gets roll-backed. As resultshows the error log information still available in error_logs table but other data fromat_test table got roll-backed.

* Result is based on current prototype of autonomous transaction.

Autonomous Transaction Use-cases: Auditing

Autonomous transaction is useful for auditing purpose also as explained below:

As we can see from above picture, although customer order for item got roll-backedbecause of unavailability of items but still customer information’s are committed inaudit table for future use.

MTx Scope ATx Scope

ATx

MTx

MT scope begins the main transaction, MTx insert buy order

into a table

MTx invokes the autonomous transaction scope (AT scope).

When AT scope begins, MT scope suspends

AT updates the audit table with customer information and

commit.

MTx seek to validate the order, finds that the selected items are unavailable, therefore rollback

the main transaction.

Contents

• Background





• Conclusion

Autonomous Transaction by other DBs

Oracle• Autonomous Transaction was

supported by oracle starting from 8i version, which was released in 1999.

• An autonomous transaction is defined in the declaration of pl/sql block. This can be an anonymous block, procedure or trigger.

• This is done by adding the statement ‘PRAGMA AUTONOMOUS TRANSACTION;’ anywhere in the declaration block.

IBM DB2• Autonomous transaction was

supported by DB2 starting from 9.7 version, which was released in 2009.

• In DB2, autonomous transaction are implemented through autonomous procedure.

Autonomous Transaction by other DBs Contd…

Oracle• Example:

PROCEDURE test_autonomous IS

PRAGMA AUTONOMOUS TRANSACTION;

BEGIN

insert…

commit…

END test_autonomous;

IBM DB2• Example:

CREATE OR REPLACE your_procedureLANGUAGE SQL AUTONOMOUS

BEGIN

insert…

commit…

END;

Contents

• Background





• Conclusion

Conclusion

Autonomous Transaction is very useful specifically for auditing (e.g. in retailsector, banking sector etc) and error logging.

This feature can be one of very attractive feature while comparing to other opensource database available.

Thank You

Technology

Autonomous transaction