Detailed Spring Transaction Properties

Spring declarative transactions allow us to be freed from complex transaction processing. There is no further need to handle these operations, such as getting connections, shutting down connections, committing transactions, and rolling back. There is no further need for us to handle a large number of try...catch...finally code in a transaction-related approach.

When we use spring declarative transactions, we have a very important concept of transactional attributes. Transaction attributes are usually composed of the propagation behavior of the transaction, the isolation level of the transaction, the transaction time-out value, and the transaction read-only flag. When we make a transaction division, we need to define the transaction, that is, to configure the properties of the transaction.

Spring defines these properties in the Transactiondefinition interface for Platfromtransactionmanager to use, Platfromtransactionmanager is the core interface of spring transaction management.

TransactionDefinition
public interface TransactionDefinition ...{
int getPropagationBehavior();
int getIsolationLevel();
int getTimeout();
boolean isReadOnly();
}

GetTimeout () method that returns the number of seconds a transaction must complete.

IsReadOnly (), transactions are read-only, and the transaction manager is able to optimize against this return value to ensure that transactions are read-only.

The Getisolationlevel () method returns the isolation level of a transaction from which the transaction manager controls another transaction to see what data is within the transaction.

Five different transaction isolation levels defined in the Transactiondefinition interface

Isolation_default This is a platfromtransactionmanager default isolation level that uses the default transaction isolation level of the database. The other four with

JDBC Isolation Level Phase Object

Isolation_read_uncommitted This is the lowest isolation level for a transaction, and it allows a transaction to see uncommitted data for this transaction. This isolation level produces dirty reads, no repeat reads, and Phantom reads.

For example:

Mary's original salary was 1000, and the treasurer changed Mary's salary to 8000, but did not submit the transaction

Connection con1 = getConnection();
con.setAutoCommit(false);
update employee set salary = 8000 where empId ="Mary";

Meanwhile, Mary is reading her salary.

Connection con2 = getConnection();
select salary from employee where empId ="Mary";
con2.commit();

Mary found her salary turned to 8000, with a rapturous joy!

When the financial discovery was wrong and the transaction rolled back, Mary's wages turned 1000.

Con1

Con1.rollback ();

Like this, Mary remembered that the salary of 8000 is a dirty data.