Announcement Announcement Module
Collapse
No announcement yet.
transaction mgmt for Hibernate managed objects Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • transaction mgmt for Hibernate managed objects

    is it possible to add declarative transaction management using the TransactionProxyFactoryBean class to Hibernate managed objects?

    Example will be appreciated.. or any documentation??

  • #2
    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?

    Comment


    • #3
      What would happen to the Hibernate Session if you were to transactionally advise an operation on a persistent object? I'm finding it hard to think of a valid use case.

      Comment


      • #4
        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.

        Comment

        Working...
        X