When you declare a transaction in Spring transaction management you can define certain attributes for that transaction. These attributes define how the transaction will function.
Spring transaction attributes
Following attributes define the Spring transaction settings-
Propagation settings in Spring transaction
Propagation behavior decides how a method will work in a transaction context. Transaction management in Spring framework defines seven propagation settings. These propagation settings are defined as final static int in org.springframework.transaction.TransactionDefinition interface.
- PROPAGATION_REQUIRED- This propagation setting in Spring transaction management means that the method runs in a current transaction if exists. A new transaction is created if none exists.
- PROPAGATION_REQUIRES_NEW- This propagation setting creates a new transaction, suspending the current transaction if one exists.
- PROPAGATION_MANDATORY- This setting means that the method must run within a transaction. An exception is thrown if no current transaction exists.
- PROPAGATION_SUPPORTS- This propagation setting supports a current transaction if exists and run with in it; if no transaction exists then the method executes non-transactionally.
- PROPAGATION_NOT_SUPPORTED- This propagation setting means that the method doesn't support a transaction. If a transaction exits it is suspended when the method is executed.
- PROPAGATION_NEVER- This propagation setting doesn't support a transaction. An exception is thrown if transaction exists.
- PROPAGATION_NESTED- This propagation setting means that the method runs in a nested transaction if there is an existing transaction. If no transaction exists then this setting behaves like PROPAGATION_REQUIRED.
Isolation levels in Spring transaction
This property defines the extent to which this transaction is isolated from the work of other concurrent transactions. Before going into isolation levels defined by Spring transaction management, let’s see what problems may occur due to concurrent transactions.
Dirty read- This situation occurs when a transaction reads the data that is written but not committed by another transaction. As example Transaction T1 reads a row that is updated by Transaction T2 but not yet committed. Later T2 is rolled back which means T1 has read the data which is not valid now.
Non-repeatable reads- This scenario occurs when a transaction reads the same data twice and gets a different value every time. As example transaction T1 reads a row, another transaction T2 updates the same row and commits. T1 reads the same row again and gets a different value. Phantom reads- In this scenario a transaction executes the same query to read a set of rows and gets additional set of rows in different executions. As example Transaction T1 executes a query to fetch some rows based on some condition, transaction T2 inserts rows that satisfies that condition. T1 runs the query again and gets the additional rows in next execution of the same query. To mitigate the problems because of these scenarios Spring transaction management defines isolation levels to keep a transaction isolated from other concurrent transactions. Isolation levels as defined in Spring transaction management are as follows, these isolation level settings are defined as final static int in org.springframework.transaction.TransactionDefinition interface.- ISOLATION_DEFAULT- This setting means that the default isolation level of the underlying datastore is used.
- ISOLATION_READ_UNCOMMITTED- This level allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed. Using this setting means that dirty reads, non-repeatable reads and phantom reads can occur.
- ISOLATION_READ_COMMITTED- This isolation level prohibits a transaction from reading a row with uncommitted changes in it. Using this setting means non-repeatable reads and phantom reads can occur only dirty reads are prevented.
- ISOLATION_REPEATABLE_READ-This level prohibits a transaction from reading a row with uncommitted changes in it, and it also prohibits the situation where one transaction reads a row, a second transaction alters the row, and the first transaction re-reads the row, getting different values the second time. Using this setting means dirty reads and non-repeatable reads are prevented, phantom reads can occur.
- ISOLATION_SERIALIZABLE- Using this isolation level means dirty reads, non-repeatable reads and phantom reads all are prevented.
Time out
You can define a time interval in seconds for the transaction to finish. If a transaction keeps running for a long time rather than keep on waiting for transaction to finish, you can provide time out in seconds. Transaction will automatically roll back after those many seconds are elapsed and it has not finished.
Note that timeout settings will not get applied unless an actual new transaction gets started. As only PROPAGATION_REQUIRED, PROPAGATION_REQUIRES_NEW and PROPAGATION_NESTED can cause that, it usually doesn't make sense to specify those settings in other cases.
Read only
By using read only property with the transaction you indicate that the transaction will only read the data won’t modify it. This property provides a chance to optimize transaction.
Roll back
Using this setting you can define for which exceptions transaction has to be rolled back. By default, transactions are rolled back only on runtime exceptions. Using roll back property you can provide specific exceptions (both checked exceptions and runtime exceptions) for which transaction has to be rolled back.
You can even define the no roll back rules specifying the exceptions for which the transaction should not be rolled back.
That's all for this topic Spring Transaction Attributes - Propagation And Isolation Level Settings. If you have any doubt or any suggestions to make please drop a comment. Thanks!
>>>Return to Spring Tutorial Page
Related Topics
You may also like-
No comments:
Post a Comment