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

[Cameron B. <ca...@br...>]

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