Declarative transaction versus software transaction
If we go to a programmatic transaction, we write
Session session=sessiongFactory.openSession();
Transaction tx=session.buildTransaction();
And for a session, we can build as many transactions as we want.
So, we have the first session object than we get the transaction object.
While in a declarative transaction, if we declare an annotation @Transaction
at the service level. "When this Service method is called, the transaction will be open", so there is no session information here. Then in Tao we write
Session session=sessiongFactory.getCurrentSession();
Here we have first Transation then Session,
Can anyone help me understand how spring manages this declarative transaction.
source to share
As per the documentation method, sessiongFactory.getCurrentSession () gets the current session and the current session is controlled by the CurrentSessionContext . for use.
The documentation also contains this explanation for backward compatibility: if CurrentSessionContext is not configured, but JTA TransactionManagerLookup is configured , the default will be JTASessionContext imp.
the JTASessionContext implementation will generate sessions as needed, provided the JTA transaction is in effect. If a session is not already associated with the current JTA transaction at the time currentSession () is called , a new session will be opened and associated with that JTA transaction.
source to share
With Spring declarative transaction, you can apply @Transactional at the method and class level. It is enabled through the AOP proxy . Combining AOP with transactional metadata results in an AOP proxy that uses TransactionInterceptor in conjunction with an appropriate PlatformTransactionManager implementation to manage transactions around method calls.
Conceptually, a method call in a transactional proxy looks like this:
When using a proxy, you should only apply the @Transactional annotation to publicly visible methods. If you annotate protected, private, or package-visible methods with @Transactional annotation, no error occurs, but the annotated method does not show the configured transaction parameters.
All transactions are associated with a session. Transactions are initiated at the service layer, but they must be associated with a session to be committed. The first transaction ends, then the session is closed. A session can also span multiple transactions. If you are using hibernate, Spring uses the hibernate managed transaction manager, which is responsible for merging transactions with the hibernate session.
source to share
Spring transaction management abstracts transaction processing and decouples the transaction demarcation logic (e.g. @Transactional) from the actual transaction manager (e.g. RESOURCE_LOCAL, JTA).
The problem with programmatic transaction is that you are tying your application code to the transaction management logic. On the other hand, Spring allows you to switch from JpaTransactionManager to JtaTransactionManager with only some configuration (no need to change application code).
Spring only creates a transaction context that is used internally TransactionInterceptor
to execute the real transaction management hooks.
-
For RESOURCE_LOCAL, transactions are processed using the JDBC's
Connection
commit () and rollback () methods . -
For JTA, transactions are processed using the JTA's
UserTransaction
commit () and rollback () methods .
source to share
Everything is explained in the docs . You can also take a look at Spring ORM integration .
Basically, Spring creates a proxy that intercepts the call to transactional methods and starts the transaction before delegating the call to the target method and ends the transaction when the target method returns.
source to share