I am new to spring. Studying transaction management topic..came across that spring supports two types of transaction management - programmatic and declarative. But i could not make out the clear difference between both..Had read that programmatic means you will define the boundaries of transaction like when to commit etc..And in case of declarative, you need to configure it in AOP style xml or using annotations. Which is following - programmatic or declarative?
And if i am using like following
which one is this?
Hello and welcome to the Ranch! It sounds like you answered your own question. Perhaps you are just looking for validation?
The first would be declarative (assuming the transaction advice for this method is configured in your configuration). It is declarative because Spring is managing the transactions, not your application code. It is important to note that its not common for people to use the AOP style xml much anymore. Its simpler both from a configuration and readability standpoint to use the @Transactional annotation to apply transactional advice to methods. In 99% of cases this is sufficient.
The latter example is programatic. This is because the application code is managing the transaction.
kuldeep sidhu wrote:Bill,
What if i do not use Transactional annotation/transaction advice or any other annotation for this method? Which case it would be then.?
If you are not managing the transaction programatically, and there is no annotation or transaction advice then it would be no transaction at all. In the snippet you presented this would result in an exception.
kuldeep sidhu wrote:And in which real time scenarios should be use programmatic? Will declarative not be suffice for all?
My recommendation as a general rule of thumb:
1. Use declarative with the @Transactional annotation. In almost all cases this is all you need. It is easy to configure, and to read and maintain.
2. Use programmatic only if you need fine grained control not possible above. You will know it when you see it, but it is not that common to need this.
3. Use custom advice if you have special business logic that must be applied to every transactional use case. This is not possible to do with option 1 and would be duplicate code using option 2. Again I don't run into this often.