I am just reading the spring-mybatis.xml,here are some code of transaction-manager:
I want to know why some methods defines as "REQUIRED" or "SUPPORTS"?How to think about it and decide which to choose?
Your question is, I think it's about Spring transaction and it's depend on your business logic and how you can control spring transaction.
To understand the Spring transaction "REQUIRED" or "SUPPORTS", you need to understand spring transaction definition. This transaction definition types are come from org.springframework.transaction.TransactionDefinition class. But first you need to understand 1)Spring transaction types and then 2)Spring transaction Definition.
1) Spring supports two types of transaction management:
Programmatic transaction management: This means that you have manage the transaction with the help of programming. That gives you extreme flexibility, but it is difficult to maintain.
Declarative transaction management: This means you separate transaction management from the business code. You only use annotations or XML based configuration to manage the transactions.
2) Spring Transaction Definition
PROPAGATION_REQUIRED：
Spring REQUIRED behavior means that the same transaction will be used if there is an already opened transaction in the current bean method execution context. Create a new one if none exists.
In short this means that if an inner(2nd Transaction) method causes a transaction to rollback, the outer(1st Transaction) method will fail to commit and will also rollback the transaction.
PROPAGATION_SUPPORTS:
Support a current transaction; execute non-transactionally if none exists.
Understandanding these "REQUIRE" "SUPPORTS" is not enough, as I mentioned to you that you need to understand all Spring definition under org.springframework.transaction.TransactionDefinition class.
Unfortunately, I had one power point about this Spring types and transaction which I wrote at Dec 2014 in slideshare website.
Spring Transaction Management
In this slide, I added very important point about Spring transaction in power point note session. So please not only refer to slide content but also refer to slide note session. Hope it help.
Example, refer as power point notes session too for more understanding about Spring transaction definition.
Edited:
Propagation Means: Typically, all code executed within a transaction scope will run in that transaction. However, you have the option of specifying the behavior in the event that a transactional method is executed when a transaction context already exists. For example, code can continue running in the existing transaction (the common case); or the existing transaction can be suspended and a new transaction created. Spring offers all of the transaction propagation options familiar from EJB CMT. To read about the semantics of transaction propagation in Spring, see Transaction Propagation
Related
I am trying to figure out why #Transactional does not rollback data in envers audit table after each test and how to fix it.
How can I make that happen in spring integration tests?
I have tried with #DirtiesContext and that makes it work but it's rather workaround and makes tests run much longer which I don't like.
Does any of you have any idea how to make it work?
Hibernate Envers acts as a transaction-commit-time audit solution. What that ultimately means is that all the persistence changes that happen during a transaction are examined and a set of work unit operations are cached in memory. In short, the only time Envers flushes operations to the audit schema is immediately before the commit of a successful transaction.
So how does this all work from a Hibernate point of view?
Hibernate Envers registers 2 very critical callback operations with Hibernate ORM when a transaction that operates on an audited entity is detected, a before and after transaction completion callback. The before callback is what actually performs the flushing of the audit changes to the audit tables and the after is responsible for cleaning up any resource allocations that are related to the transaction.
The only time that the before callback actually happens is when the hibernate transaction coordinator is asked to commit the transaction. If the transaction has been marked for rollback when the commit is requested, then the before callback is skipped.
The after callback always happens no matter the transaction status.
It would seem whats likely happening is #Transactional is creating the transaction boundary and the method is then invoked to perform its operations and when the method exits, the annotation forces a transaction commit leading to the observed behavior.
I can see a few options for you:
Override transaction behavior for tests to be read-only.
Design tests to clean-up their test data after validating the test use case.
Design tests to work even if existing test data exists in the tables.
Disable Envers via configuration if it isn't needed as a part of that integration test.
I have a spring application which is based on Spring Batch. By default spring batch introduces transaction for its steps (i.e. at reader,writer and processor) . There are certain stages where I don't really need transaction to be enabled. Because transaction is enabled unnecessary for these methods its giving me some runtime errors as I am making call to two different databases in one method.
Is there any annotation which spring provides to DISABLE transaction for a specific set of methods ?
OR is there anything available in spring batch which can allow me to get rid of transaction either completely or declarative
I am even open to the solution which can disable transaction globally.
Any link , paper will greatly be appreciated.
Thanks in advance
Samir
Spring Batch is inherently transactional. Even if your datasources are not transactional, the semantics of the JobRepository require it. The closest you can get with Spring Batch and not being transactional is using the ResourcelessTransactionManager. This transaction manager is essentially a no-op transaction manager that just keeps track of if an operation is within the scope of a transaction or not.
I went through Spring transaction management. I have a very simple question assume in a banking application with Spring Hibernate Integration is it mandatory to use #Transactional on credit & debit methods. If I don't want a rollback still do I have to put the methods in a transaction scope??
If you are asking technically whether Hibernate calls have to be in a transaction, the answer is no. Each call (update, insert, or delete) will be done as an atomic action. After the function returns the request to the database will be complete. When the database actually commits the change is up to Hibernate, the driver, and the database itself.
If you are asking whether or not you should put credits or debits into a transaction state, the answer depends on the requirements of the application.
It depends on you haw you handle your debit and credit. Perhaps there is some level configuration you can provide to #Transactional. If you need to have more flexible transaction, you may opt for programmatic transaction management instead of declarative transaction management. As far as Spring is concerned, it do not restrict you in any way, its totally up to you how you want to handle your transactions.
In spring framework, there is transaction semantics: PROPAGATION_REQUIRED, ISOLATION_ONLY. What does that mean?
Here, you will find all isolation levels and types of propagation managed by the latest version of Spring :
http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/transaction/TransactionDefinition.html
"ISOLATION_ONLY" is not part of it.
You can read about Spring Transactions in the documentation.
You are specifically asking about Transaction Propagation, which is section 10.5.7 of the documentation.
See JavaDoc for TransactionDefinition, it describes all propagation behaviors in great detail.
In short PROPAGATION_REQUIRED means that a given method requires a transaction to run. If it is run from within an existing transaction, it will join it. If there is no transaction in the current execution thread, the container will create one for you and commit when you leave the method.
I have never heard about ISOLATION_ONLY, where have you seen it?
See also:
EJB3 Transaction Propagation
my confusion related to this matter is that how we can use a previously created transaction? or in other words how many threads a transaction could be related to?
A transaction can be related to only one thread in spring. Well, with some effort you can make it a long-running transaction, but that's an anti-pattern afaik.
REQUIRES_NEW means that whenever the program flow enters the annotated method, a new transaction will be started regardless of any existing transaction.
REQUIRED means that an existing transaction will be reused, or if there's no existing transaction a new one will be started.