This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
No announcement yet.
transaction mgmt for Hibernate managed objectsPage Title Module
This doesn't make sense to me. It is usually necessary to run service (and/or Hibernate DAO methods) transactionally. Those services (and also DAOs) are declared as singleton beans in Spring's application context and it can easily became transactional using TransactionProxyFactoryBean .
But why to apply transaction management to Hibernate managed objects?
the valid use case would be a case where you construct a rich domain model and instead of facading it with a service allow client interact with it directly. So for example, suppose you have an Applicant and Address objects as part of your domain model, and applicant can have multiple addresses, so you can add an address. Now there are two ways of making it happen:
1. Create Facade and have a method add (Applicant a, Address addr) that will actualy be transactional method that will take care of adding an address to the applicant's record. Facade is the service (bean) managed by spring, hence making add transactional is not a problem.
2. Have a method on Applicant object that would be add (Address). This however will have to be somehow talking back to spring to take care of transactions for me. Note also Applicant can not be a spring managed service since hibernate is probably the one that creates it.
While method 1 is acceptable the method 2 is more natural. So if I develop domain model for someone else to use (in presentation tier) I would rather employ method 2, because there is less stuff to get confused about and hence for me to explain to people.
Anyway to make long story short, the way to deal with the problem, in my opinion, is to use AspectJ in conjunction with spring. The major reason for using AspectJ is that you can not inject spring's capabilities into something that is not managed by spring (in this case the classes are managed by hibernate). So you will have to precompile into hibernate managed classes the awareness of Spring thru AspectJ aspects.