Tapestry + Hibernate + Spring and using the "Open View In Session" pattern.

[Random Tapestry User <ta...@comcast.net>]

I have an app that uses Tapestry / Hibernate / Spring, and have read a 
good deal about the Open Session In View pattern and using Spring's 
provided filter for implementing that.

I'm looking for input from anyone who uses this approach and if they 
recommend it.
Also looking for any input on pitfalls to avoid.

I've read references that if a Hibernate exception is thrown then the 
session is in an inconsistent state, but I'm unclear as to what do 
actually do with that session if that occurs. This assumes that I will 
have control at the point the exception is thrown. I'm not sure there 
will be a point of control where I can detect if the session is no 
longer any good and dispose of it so that a bad session is returned to 
the pool. I'm not sure if Spring's filter accounts for that, guess I'll 
have to dig into the source.

Note, if I sound a bit dim-witted about Hibernate/Spring, it's because 
I'm primarily responsible for the View layer of the app a friend and I 
are creating. He is providing the Model, and the controller, but we 
realize that the View is going to have to know just a little bit more 
about the persistence layer to pull this off properly.

Any/all input is welcome.

Thanks all,
tappapp

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org

Re: Tapestry + Hibernate + Spring and using the "Open View In Session" pattern.

[Shawn Church <sh...@boxity.com>]

I'm currently in beta testing for a project which uses
Tapestry/Hibernate/Spring and Spring's Open Session in View Filter, so
maybe I can contribute something.

My experiences were fairly positive overall, but I would also say that
I've spent a lot of time chasing down silly Hibernate exceptions and
getting things "just right" to work reliably.  Hibernate is easy and
reliable 95% of the time, but that last 5% can be annoying.  My
applications tend to be fairly complex, and I'm working with multiple
legacy databases, but my applications are all fairly typical real-world
examples.

I worked with Hibernate using the various recommended methods
(ThreadLocal session, etc.) for a while before reluctantly introducing
Spring into the mix.  Spring has helped a lot with managing Hibernate
sessions and transactions, and it was definitely worth the effort.  The
main downside (and upside) to Spring's OSIV filter is that to use it
effectively you really need to also make full use of Spring's dependency
injection / IoC features.  In my case, I ended up adding a few dozen DAO
service interfaces and implementations.  Spring creates and enhances
these service classes, injecting class properties as appropriate (as
configured in applicationContext.xml).

In the Spring docs, the recommended method for getting ahold of Spring
beans with Tapestry is to add a springContext property to your Tapestry
global object class.  Then in your page specs you can get the Spring
beans by name.  This has worked very well.

One of my goals was to completely separate my view layer from the
persistence layer, and using Spring's IoC mechanisms made this possible.
 The only hint of Hibernate in my presentation layer is that I wound up
creating a generic HibernateService bean since at times I have to
manually attach or evict my persistent objects to/from the Hibernate
session.

Another downside to using Spring with Hibernate is that I sometimes feel
too far removed from Hibernate, especially when I need to explicitly
perform some Hibernate session-related operation.  My service classes
all extend Spring's HibernateDaoSupport class, so all Hibernate
operations are performed through the Spring HibernateTemplate class. 
Hibernate queries work fine, but they end up looking like
getHibernateTemplate().load(My.class, id) or
getHibernateTemplate().find("whatever").  This can be a little
challenging when you need to ask a question on the Hibernate forum.  I
typically get little or no help from the Hibernate people since my
questions are often muddied by the Spring layer.

Using Spring's OSIV filter, I've had the best results using the
single-session-per-request model (singleSession=true).  However, I
fairly frequently have to contend with Hibernate
NonUniqueObjectExceptions, since the same session will often be open
while I traverse Tapestry pages.  This is especially common when using
cascade="save-update" or greater, since for example one Tapestry page
might present a list of objects to select from, which triggers another
page to edit/view the selected item.  The second page will sometimes
need to reassociate the persistent object with the open session, but the
previous page may have implicitly already loaded the object due to the
list generation.

These are just a few of my experiences, and everything technically
"works", but I don't feel my code is as stable now as when I used
straight JDBC in the past.  I really want to like Hibernate, because it
has many very powerful features and it seems to be fairly high-quality
code, but I don't feel it is designed terribly well for typical use
cases.  Hibernate 3 (which I am now using) is an improvement, but if I
had it to do over on my current project, I would have explored a JDO
implementation such as JPox.  Even so, I will probably stick with
Hibernate, since I believe it will be around for a while and I think
many of the current "issues" will eventually be ironed out.  My current
project is not huge (around 35,000 lines of Java and html), so Spring is
probably overkill, but it was also not a big investment to incorporate.

As far as your Hibernate exceptions versus inconsistent state question,
I haven't seen this to be a problem.  If you are migrating from 
Hibernate 2.1 to 3.0, you should read the migration guide carefully. 
Exceptions in Hibernate3 are unchecked, so you will want to be aware of
that.  Also, the comments about lazy initialization are not talking
about lazy collection initialization, but rather are referring to lazy
loading of objects through proxies.  In my case, it was best to set
default-lazy="false" as it was in 2.1.

I've only used Hibernate for the last 6 months, and Spring for the last
couple of months, so I reserve the right to change my opinions as I find
new solutions or learn more of Hibernate's internals.  If you plan to
use Hibernate, I would highly recommend Spring.  

Shawn


Quoting Random Tapestry User <ta...@comcast.net>:

> I have an app that uses Tapestry / Hibernate / Spring, and have read
> a 
> good deal about the Open Session In View pattern and using Spring's 
> provided filter for implementing that.
> 
> I'm looking for input from anyone who uses this approach and if they
> 
> recommend it.
> Also looking for any input on pitfalls to avoid.
> 
> I've read references that if a Hibernate exception is thrown then the
> 
> session is in an inconsistent state, but I'm unclear as to what do 
> actually do with that session if that occurs. This assumes that I
> will 
> have control at the point the exception is thrown. I'm not sure there
> 
> will be a point of control where I can detect if the session is no 
> longer any good and dispose of it so that a bad session is returned
> to 
> the pool. I'm not sure if Spring's filter accounts for that, guess
> I'll 
> have to dig into the source.
> 
> Note, if I sound a bit dim-witted about Hibernate/Spring, it's
> because 
> I'm primarily responsible for the View layer of the app a friend and
> I 
> are creating. He is providing the Model, and the controller, but we 
> realize that the View is going to have to know just a little bit more
> 
> about the persistence layer to pull this off properly.
> 
> Any/all input is welcome.
> 
> Thanks all,
> tappapp
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org