Welcome to the new Spring.io forums!
If this is your first visit, be sure to check out the
by clicking the link above, and for security reasons, use the
forgot password link to reset your password..
You may have to register before you can post: click the register
link above to proceed. To start viewing messages, select the forum that you want to visit
from the selection below.
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.