These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 
Author Message
 Post subject: AOP + Hibernate
PostPosted: Wed Aug 24, 2005 12:19 pm 
Newbie

Joined: Wed Aug 24, 2005 12:09 pm
Posts: 2
Hello,
I'm making a case for my design team regarding the use of Aspect Oriented Programming (AOP) and Hibernate. It would seem to me that these two technologies are quite compatible, since you can design an AOP pointcut to "wrap" your hibernate-aware methods inbetween sessionFactory.openSession() and session.close().

I'm trying to find out if this is being done by others? Are there any users here using this approach? Any pros/cons to mention?

Thanks,
George.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 24, 2005 12:23 pm 
Senior
Senior

Joined: Thu May 12, 2005 11:40 pm
Posts: 125
Location: Canada
This has several problems.

Firstly, you are inventing your own declarative transaction management solution. AOP is a good tool to use for this, but there are containers which do this for you already, and probably more robustly and correctly.

Second, full-on AOP is not usually necessary. It is enough to use more coarse grained interception, such as a servlet filter and avoid introducing AOP dependencies.

Thirdly, wrapping each method or even dao class in its own session prevents multiple daos from collaborating using the same session, which is often useful.

Look into the Thread Local Session pattern and the HibernateUtil class. Unless you have a container managing your transactions, this is almost certainly the best and simplest way to solve this common problem.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 24, 2005 12:35 pm 
Regular
Regular

Joined: Mon Apr 25, 2005 9:22 am
Posts: 62
Location: Bucharest/Romania
Some comments:

Nebob wrote:
Firstly, you are inventing your own declarative transaction management solution. AOP is a good tool to use for this, but there are containers which do this for you already, and probably more robustly and correctly.


Agree.
Nebob wrote:
Second, full-on AOP is not usually necessary. It is enough to use more coarse grained interception, such as a servlet filter and avoid introducing AOP dependencies.


It very much depends on the granularity he wants to obtain. Introducing aop dependencies is like introducing any other dependency so this is not wrong from the beginning.
Moreover, there have been benchmarks driven for comparing proxy-based vs bytecode aop solutions where the later are performing better.

Nebob wrote:
Thirdly, wrapping each method or even dao class in its own session prevents multiple daos from collaborating using the same session, which is often useful.


This is definitely true. Most probably the aspects that would solve correctly this would be perthread, but I am not aware of a bytecode aop solution having this option (it has been removed in previous versions).

Concluding: as a theoretical demo, this is one of the best ideas, but recreating the wheel for production it's not.

take care,
:alex |.::the_mindstorm::.|


Top
 Profile  
 
 Post subject:
PostPosted: Wed Aug 24, 2005 12:52 pm 
Newbie

Joined: Wed Aug 24, 2005 12:09 pm
Posts: 2
OK these comments are useful to me. Although, on the second point; I wouldn't be introducing AOP soley for this purpose; our project will use it for logging and tracing already.
Anyone else want to weigh in?


Top
 Profile  
 
 Post subject: AOP
PostPosted: Wed Aug 24, 2005 1:03 pm 
Expert
Expert

Joined: Fri Jul 22, 2005 2:42 pm
Posts: 670
Location: Seattle, WA
Relying on AOP for providing proper Hibernate environment ( session availability, transaction propagation and error handling) is very convenient and robust approach. I have used it on production for couple of years already.

And that is exactly what Spring is doing with Hibernate interceptor,
http://static.springframework.org/sprin ... eptor.html
same thing easily could be done with other AOP frameworks like HiveMind - see HiveTranse utilities
http://hivetranse.sourceforge.net/
or AspectWerks/AspectJ.

See also my AOP frameworks comparison http://kgionline.com/presentations/aop_test.jsp

_________________
--------------
Konstantin

SourceLabs - dependable OpenSource systems


Top
 Profile  
 
 Post subject: Re: AOP + Hibernate
PostPosted: Wed Aug 24, 2005 1:21 pm 
Senior
Senior

Joined: Tue Aug 03, 2004 2:11 pm
Posts: 142
Location: Somerset
blackfrancis75 wrote:
Hello,
I'm making a case for my design team regarding the use of Aspect Oriented Programming (AOP) and Hibernate. It would seem to me that these two technologies are quite compatible, since you can design an AOP pointcut to "wrap" your hibernate-aware methods inbetween sessionFactory.openSession() and session.close().

I'm trying to find out if this is being done by others? Are there any users here using this approach? Any pros/cons to mention?

Thanks,
George.


No need for you to write it, its all be done already, and works fantistically well. Never again will you have to worry about opening or closing sessions, or messign aroudn with transactions:

http://www.springframework.org/docs/wik ... rnate.html

I've seen loads of posts that involve openign and closing sessions, and with Spring that is all handled for you, and you can get on with your business logic, as using Spring and Hibernate otgether makes your DB access easy peasy !

_________________
On the information super B road


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.