What type of transaction management strategy we should use in Spring?
Declarative or Programmatic?
Which one is better and under what situation one should use it?
Can you give any proper examples or tutorial about it.
Also want to know that what is the latest things we should use while write database codes in spring?
What is the alternative for HibernateTemplate?
Programmatic Transaction Management
Allows us to manage transactions through programming in our source code.
This means hardcoding transaction logic between our business logic.
We use programming to manage transactions
Flexible, but difficult to maintain with large amount of business logic. Introduces boilerplate between business logic.
Preferred when relative less transaction logic is to be introduced.
Declarative Transaction Management
Allows us to manage transactions through configuration.
This means separating transaction logic with business logic.
We use annotations (Or XML files) to manage transactions.
Easy to maintain. Boilerplate is kept away from business logic.
Preferred when working with large amount of Transaction logic.
They are not mutually exclusive.
You can use decalrative transaction management (#Transactional) in most of cases, and fall back to programmatic transaction management (TransactionTemplate) when you face limitations of Spring AOP (see 11.5.1 Understanding the Spring Framework's declarative transaction implementation) or need to control transactions in more complex ways.
Spring offers both programmatic and declarative transactions.
Programmatic means you have transaction management code surrounding your business code.
This gives extreme flexibility, but is difficult to maintain and, well, boilerplate.
Declarative means you separate transaction management from the business code.
You can use annotations or XML based configuration.
programmatic management is more flexible during development time but less flexible during application life
declarative management is less flexible during development time but more flexible during application life
http://docs.spring.io/spring/docs/3.0.x/reference/transaction.html
Declarative Transaction Management allows to eliminate any dependencies on the transaction framework from the Java code. The four participants to provide the transaction support are transaction manager, proxy factory, transaction interceptor, and a set of transaction attributes.
Suggest to use Declarative Transaction Management, Alternative for HibernateTemplates either NamedJDBCTemplate or simpleJDBCTemplate
http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/transaction.html#tx-decl-vs-prog
and
http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/transaction.html
in general.
examples:
http://www.springbyexample.org/examples/hibernate-transaction-annotation-config.html
New features: I suggest using DI with SessionFactory. Also take a look at 3.1 new feature: Hibernate 4 support. see http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/new-in-3.1.html#d0e1385
Programmatic transaction management is usually a good idea only if you have a small number of transactional operations. For example, if you have a web application that require transactions only for certain update operations, you may not want to set up transactional proxies using Spring or any other technology. In this case, using the TransactionTemplate may be a good approach. Being able to set the transaction name explicitly is also something that can only be done using the programmatic approach to transaction management.
On the other hand, if your application has numerous transactional operations, declarative transaction management is usually worthwhile. It keeps transaction management out of business logic, and is not difficult to configure.
There are two types of Transaction management that Spring supports:
1. Programmatic Transaction Management: Transaction is managed with the help of programming and provides extreme flexibility, but it is difficult to maintain.
2. Declarative Transaction Management: Transaction management is separated from business code and only annotations or XML based configurations are used to manage the transactions.
Related
What is the point of using spring transaction while we have database level transaction ?
If you use mysql, oracle or any other db in java, they provide methods to make things inside transaction then why spring transaction if I can do transaction using java DB driver methods ?
It's another layer of abstraction over the database transaction API. So if you wanted to use multiple databases with global transactions, Spring would allow you to do this. While I have never done it, I believe it would allow you to use DB2 and Hibernate together, for example.
Generally, what I've found is, if a feature is available in Spring, it's because there is a use case for it. They don't just put things into the framework without a reason.
Also, Spring provides declarative transaction demarcation, which produces more readable and maintainable Java code. The declarative approach lets us change the transaction strategy easily, without changing the code.
The Declarative transaction management approach allows you to manage the transaction with the help of configuration instead of hard coding in your source code. This means that you can separate transaction management from the business code. You only use annotations or XML based configuration to manage the transactions
We used Spring AOP along with Hibernate using this transaction strategy Here is an example, Spring AOP transaction mangement with Hibernate.
We are currently using Spring 3.2.3 + JPA (Hibernate). We use aspects for transaction support as opposed to annotations. We write out own entity services (read: repositories) to abstract the persistence away from our application.
I've read a lot about Spring Data and feel it would make our code considerably cleaner and more robust. I wonder though, are there any gotchas that I should consider before transitioning?
Thanks
If you're already on JPA the transition should be as easy as it can be: activate the repositories, point the infrastructure to your EntityManagerFactoryBean and off you go.
Transactions should just work fine as well. The annotation based usage within Spring Data is selectively activated for the repository beans only. They are configured to take part in existing transactions by default, so any custom larger scoped transaction setting should be in effect already.
I want to implement transaction using Spring's transaction management feature. But I'm not sure which is better(AOP vs #Transactional). Do both features work correctly? Is there any difference in development efficiency?
(Added)
Here AOP means "using AspectJ without using #Transactional annotation explicitly"
(Added)
I want to know difference of annotation-config and XML-based configuration
I've wondered this myself. I found a good discussion of this topic on the Spring forum.
Below I've summarize my take from the aforementioned link:
AOP Transactional Demarcation
Benefits:
Java code is devoid of transaction configuration which is contained instead outside of the code in configuration files
Java code has no direct dependencies on Spring libraries
Transaction management is centralized in one place
Can apply transactional boundaries to source code you can't easily modify
Drawbacks:
AOP complexity. It will not be clear from the code alone where transactional boundaries lie and developers may inadvertently break transactions by, for example, modifying method signatures where a pointcut is applied
The need to touch two locations (source code and AOP configuration) in order to apply transactional boundaries
#Transactional Spring annotation
Benefits:
Transactional boundaries are more clearly understood when examining the source code
Drawbacks:
Java code is coupled with transaction declaration (albeit only at the metadata level, but still a Spring import is required).
The discussion reminds me of JPA annotations versus JPA XML configuration. With XML based JPA configuration, entities are "cleaner", but is the separation worth the effort? Or perhaps even, is the separation harmful (it's nice to be able to open a java source file and know immediately based on the #Entity annotation that the class is an EJB)? In practice, it seems to me that most developers opt to use JPA annotations. Although, in this case unlike #Transactional, jpa annotations are a standard so that may help ease some concerns.
That said, I've been involved on projects were we've used Spring's AOP configuration to annotate a Struts2 (webwork) interceptor to allow a single transaction per request and this worked out great. In this case, we didn't really worry about transactional boundaries in our service layer or elsewhere -- everything was already participating in a transaction and since the view rendered before the interceptor closed the transaction, there was no need to apply an OpenSession/EntityManagerInView solution.
Im working with the Spring Framework 3.0.5 and the Hibernate Framework and Im starting to use now Springs Transactionmanagement. I have some questions, just to understand how Springs Transactionmanagement works.
1)
I read this things in the Spring reference:
a) Consistent programming model across different transaction APIs such as Java Transaction API (JTA), JDBC, Hibernate, Java Persistence API (JPA), and Java Data Objects (JDO).
b) Spring resolves the disadvantages of global and local transactions. It enables application developers to use a consistent programming model in any environment. You write your code once, and it can benefit from different transaction management strategies in different environments.
c) Gone are the days when the only alternative to using EJB CMT or JTA was to write code with local transactions such as those on JDBC connections, and face a hefty rework if you need that code to run within global, container-managed transactions. With the Spring Framework, only some of the bean definitions in your configuration file, rather than your code, need to change.
From a) I understand that I can use those APIs with Spring without changing the code
From b) I understand that I can use global or local transactions *without changing the code
From c) I understand that while switching between different APIs and global/local transactions I need to change the code
Now I wonder what is correct?
=> Do I need to change the code? When switching between different APIs? When switching between local and global transactions? (Or does it maybe depend on prorgammatic and declarative transaction management?)
2)
I also got an additional question: I really wonder what the use of programmatic transaction management is? Everywhere I read that declarative transactionmanagement is recommended
I read this in spring reference too:
d) With programmatic transaction management, developers work with the Spring Framework transaction abstraction, which can run over any underlying transaction infrastructure. With the preferred declarative model, developers typically write little or no code related to transaction management, and hence do not depend on the Spring Framework transaction API, or any other transaction API.
From d) I understand: with programmatic transaction management I can use any underlying transaction infrastructure... which means what? the different APIs mentioned above?
and: with declarative I do not depend on any api
=> isnt this the same? when I can use any underlying api, I do not depend on any api. I do not really understand this.
where is the difference? I only know that the declarative transaction management is more lightweight, that I have not to start the transaction by my self and catch the exception and handle it and so on. But what is the use of programmatic transaction management then?
Thank you for answering! :-)
You're over-thinking this a bit. The Spring API provides an abstract transaction model that has the same API and semantics regardless of which underlying transaction technology you use. In order to switch from one technology to another, you generally have to alter your Spring config, but the idea is that you never needs to to alter your business logic. So whether you're using local, in-VM JDBC transactions or fully distributed, two-phase-commit XA JPA-style transactions, the API usage within your Spring code is the same. Only the configuration changes.
The difference between declarative and programmatic transaction management is that with the former, you use annotations or XML config to say which bits of code are supposed to be transactional. With programmatic style, you specifically enclose transactional logic using method calls into the Spring API. Note that if you use the declarative style, then Spring will wrap your code in generated logic which uses the programmatic style. The latter is simply a more explicit and low-level version of the former. It gives you more control, but it's more verbose.
What are the advantages and disadvantages of the Session Façade Core J2EE Pattern?
What are the assumptions behind it?
Are these assumptions valid in a particular environment?
Session Facade is a fantastic pattern - it is really a specific version of the Business Facade pattern. The idea is to tie up business functionality into discrete bundles - such as TransferMoney(), Withdraw(), Deposit()... So that your UI code is accessing things in terms of business operations instead of low level data access or other details that it shouldn't have to be concerned with.
Specifically with the Session Facade - you use a Session EJB to act as the business facade - which is nice cause then you can take advantage of all the J2EE services (authentication/authorization, transactions, etc)...
Hope that helps...
The main advantage of the Session Facade pattern is that you can divide up a J2EE application into logical groups by business functionality. A Session Facade will be called by a POJO from the UI (i.e. a Business Delegate), and have references to appropriate Data Access Objects. E.g. a PersonSessionFacade would be called by the PersonBusinessDelegate and then it could call the PersonDAO. The methods on the PersonSessionFacade will, at the very least, follow the CRUD pattern (Create, Retrieve, Update and Delete).
Typically, most Session Facades are implemented as stateless session EJBs. Or if you're in Spring land using AOP for transactions, you can create a service POJO that which can be all the join points for your transaction manager.
Another advantage of the SessionFacade pattern is that any J2EE developer with a modicum of experience will immediately understand you.
Disadvantages of the SessionFacade pattern: it assumes a specific enterprise architecture that is constrained by the limits of the J2EE 1.4 specification (see Rod Johnson's books for these criticisms). The most damaging disadvantage is that it is more complicated than necessary. In most enterprise web applications, you'll need a servlet container, and most of the stress in a web application will be at the tier that handles HttpRequests or database access. Consequently, it doesn't seem worthwhile to deploy the servlet container in a separate process space from the EJB container. I.e. remote calls to EJBs create more pain than gain.
Rod Johnson claims that the main reason you'd want to use a Session Facade is if you're doing container managed transactions - which aren't necessary with more modern frameworks (like Spring.)
He says that if you have business logic - put it in the POJO. (Which I agree with - I think its a more object-oriented approach - rather than implementing a session EJB.)
http://forum.springframework.org/showthread.php?t=18155
Happy to hear contrasting arguments.
It seems that whenever you talk about anything J2EE related - there are always a whole bunch of assumptions behind the scenes - which people assume one way or the other - which then leads to confusion. (I probably could have made the question clearer too.)
Assuming (a) we want to use container managed transactions in a strict sense through the EJB specification then
Session facades are a good idea - because they abstract away the low-level database transactions to be able to provide higher level application transaction management.
Assuming (b) that you mean the general architectural concept of the session façade - then
Decoupling services and consumers and providing a friendly interface over the top of this is a good idea. Computer science has solved lots of problems by 'adding an additional layer of indirection'.
Rod Johnson writes "SLSBs with remote interfaces provide a very good solution for distributed applications built over RMI. However, this is a minority requirement. Experience has shown that we don't want to use distributed architecture unless forced to by requirements. We can still service remote clients if necessary by implementing a remoting façade on top of a good co-located object model." (Johnson, R "J2EE Development without EJB" p119.)
Assuming (c) that you consider the EJB specification (and in particular the session façade component) to be a blight on the landscape of good design then:
Rod Johnson writes
"In general, there are not many reasons you would use a local SLSB at all in a Spring application, as Spring provides more capable declarative transaction management than EJB, and CMT is normally the main motivation for using local SLSBs. So you might not need th EJB layer at all. " http://forum.springframework.org/showthread.php?t=18155
In an environment where performance and scalability of the web server are the primary concerns - and cost is an issue - then the session facade architecture looks less attractive - it can be simpler to talk directly to the datbase (although this is more about tiering.)