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

[Juergen H. <ju...@in...>]

I've already thought of that, actually, but I think it's not feasible in
general. We would not only need to proxy the Hibernate Session for this, but
also all resources returned by it, such as Query instances and Criteria
instances.

And then there's the problem of interface contract: If the Hibernate Session
interface says that it throws (unchecked) HibernateException, it would
arguably be a bit odd to throw (unchecked) DataAccessException - from the
contract point of view...

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Cameron Braid
Sent: Monday, March 14, 2005 4:11 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Hibernate3 entity names, direct
Session access


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



-------------------------------------------------------
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