Thread: [Springframework-developer] Hibernate3 entity names, direct Session access

Brought to you by: colins, jhoeller, johnsonr, robharrop, trevormarshall

springframework-developer

[Springframework-developer] Hibernate3 entity names, direct Session access

From: Juergen H. <ju...@in...> - 2005-03-13 21:50:45

We've just received a request for further overloaded methods on
HibernateTemplate: taking Hibernate3 entity names as alternative to Class
arguments, analogous to the Hibernate3 Session.

http://opensource.atlassian.com/projects/spring/browse/SPR-777

As I've replied there, I'm somewhat reluctant to add the overloaded
operations for entity names to HibernateTemplate itself. HibernateTemplate
already has quite a lot of operations on it; I'd like to avoid cluttering it
with even more overloaded methods.

Of course, like for all needs that HibernateTemplate's convenience methods
do not cover, implement a custom HibernateCallback and use the Hibernate
Session API natively. With an anonymous inner class, such a callback is
straightforward to implement, but of course more verbose than a one-line
convenience operation call.

It's worth pointing out that there is an alternative now, enabled by
Hibernate3's use of unchecked exceptions: direct Hibernate Session access
via SessionFactoryUtils.getSession - if you can live with Hibernate3's
unchecked HibernateException's getting thrown to callers.

If you can guarantee to always execute within a transaction in such a
scenario, you don't even need to call
SessionFactoryUtils.closeSessionIfNecessary, which allows you to write
straightforward direct Session access code.

public class MyDao extends HibernateDaoSupport {

  public MyObject loadMyObject(String id) throws HibernateException {
    return (MyObject) getSession(false).load("myEntityName", id);
  }
}

The advantage of this style is that there is no wrapping of the Hibernate
Session: It's plain Hibernate Session access; the only thing Spring provides
is a lookup method that returns the Spring-managed transactional Hibernate
Session.

The disadvantage is, of course, that HibernateExceptions will get thrown
as-is, which means that callers have to be coded against Hibernate-specific
exceptions when trying to handle them. If those exceptions don't get handled
explicitly in business facade code, exception mappings in error views are
affected.

At least callers don't need to declare the formerly checked
HibernateException anymore: If they don't care about exceptions thrown by
the DAO, they can simply let the now (since Hibernate3) unchecked
HibernateException through - without explicitly catching it or declaring it
in the "throws" clause.

An interesting question is whether we should always strictly recommend the
HibernateTemplate/DataAccessException approach, even in case of many custom
HibernateCallbacks. In some applications, people might not care about
generic data access exceptions, so Hibernate3's unchecked exceptions might
be acceptable...

The same applies to JDO: unchecked JDOExceptions might be acceptable as DAO
exceptions in some scenarios. Like in the Hibernate3 case, this is only
really interesting if always executing within a transaction, though: else,
DAO implementations would get cluttered with try-finally blocks for closing
resources.

Thoughts? Opinions?

Juergen

RE: [Springframework-developer] Hibernate3 entity names, direct Session access

From: Cameron B. <ca...@br...> - 2005-03-14 03:11:50

How is this for an idea :

Have a configuration option that allows spring to wrap the hibernate session
in a class that automatically converts the exceptions into spring
exceptions.

Cameron.

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behalf
> Of Juergen Hoeller
> Sent: Monday, 14 March 2005 7:50 AM
> To: spr...@li...
> Subject: [Springframework-developer] Hibernate3 entity names, direct
> Session access
> 
> We've just received a request for further overloaded methods on
> HibernateTemplate: taking Hibernate3 entity names as alternative to Class
> arguments, analogous to the Hibernate3 Session.
> 
> http://opensource.atlassian.com/projects/spring/browse/SPR-777
> 
> As I've replied there, I'm somewhat reluctant to add the overloaded
> operations for entity names to HibernateTemplate itself. HibernateTemplate
> already has quite a lot of operations on it; I'd like to avoid cluttering
> it
> with even more overloaded methods.
> 
> Of course, like for all needs that HibernateTemplate's convenience methods
> do not cover, implement a custom HibernateCallback and use the Hibernate
> Session API natively. With an anonymous inner class, such a callback is
> straightforward to implement, but of course more verbose than a one-line
> convenience operation call.
> 
> It's worth pointing out that there is an alternative now, enabled by
> Hibernate3's use of unchecked exceptions: direct Hibernate Session access
> via SessionFactoryUtils.getSession - if you can live with Hibernate3's
> unchecked HibernateException's getting thrown to callers.
> 
> If you can guarantee to always execute within a transaction in such a
> scenario, you don't even need to call
> SessionFactoryUtils.closeSessionIfNecessary, which allows you to write
> straightforward direct Session access code.
> 
> public class MyDao extends HibernateDaoSupport {
> 
>   public MyObject loadMyObject(String id) throws HibernateException {
>     return (MyObject) getSession(false).load("myEntityName", id);
>   }
> }
> 
> The advantage of this style is that there is no wrapping of the Hibernate
> Session: It's plain Hibernate Session access; the only thing Spring
> provides
> is a lookup method that returns the Spring-managed transactional Hibernate
> Session.
> 
> The disadvantage is, of course, that HibernateExceptions will get thrown
> as-is, which means that callers have to be coded against Hibernate-
> specific
> exceptions when trying to handle them. If those exceptions don't get
> handled
> explicitly in business facade code, exception mappings in error views are
> affected.
> 
> At least callers don't need to declare the formerly checked
> HibernateException anymore: If they don't care about exceptions thrown by
> the DAO, they can simply let the now (since Hibernate3) unchecked
> HibernateException through - without explicitly catching it or declaring
> it
> in the "throws" clause.
> 
> An interesting question is whether we should always strictly recommend the
> HibernateTemplate/DataAccessException approach, even in case of many
> custom
> HibernateCallbacks. In some applications, people might not care about
> generic data access exceptions, so Hibernate3's unchecked exceptions might
> be acceptable...
> 
> The same applies to JDO: unchecked JDOExceptions might be acceptable as
> DAO
> exceptions in some scenarios. Like in the Hibernate3 case, this is only
> really interesting if always executing within a transaction, though: else,
> DAO implementations would get cluttered with try-finally blocks for
> closing
> resources.
> 
> Thoughts? Opinions?
> 
> Juergen
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer