I'm converting an OracleForms application to a Java web application. Due to the structure of OracleForms, I'd like to use Hibernate's StatelessSessionImpl class instead of SessionImpl as the Hibernate Session implementation. We are also using the Spring Framework to configure Hibernate.

Since I'm using the Spring Framework's HibernateTemplate and OpenSessionInViewFilter, it is not easy to setup my DAO code to use Hibernate's StatelessSession. I thought I might be able to subclass SessionFactoryImpl to return instances of StatelessSessionImpl instead of SessionImpl when openSession() is invoked. However, this doesn't work since there is a separate interface named StatelessSession that StatelessSessionImpl implements as opposed to just implementing the Session interface and doing something to fake out the methods on the Session API that don't make sense in the context. So, I'm going to try to make an adapter class that implements the Session interface and uses an instance of StatelessSessionImpl for some operations and try to do something reasonable for the other methods defined by the Session API.

I was just wondering if there is a good reason why StatelessSessionImpl doesn't do this already before I put much effort into trying to make this work only to find out that there was a reason that this can't be done.

Nathan

Do not use the Spring stuff, even the Spring developers no longer recommend it; we never did. (Search the Spring guys blog.)

OK. I searched and see that we don't need to use HibernateTemplate
(Spring HibernateTemplates or Not).

In any case, I'd like to be able to call sessionFactory.getCurrentSession().update(myObject) where the object returned by getCurrentSession() is a StatelessSessionImpl that implements the Session interface. So, I believe I still need to make a class that implements Session ("StatelessSessionAdapter") and also subclass SessionFactoryImpl and override the getCurrentSession() method.

Any reason not to do this? Other than the fact using StatelessSession is questionable, but because of the nature of this legacy re-development, we think this makes sense in this case.

I am curious why the Hibernate developers didn't do this to start with considering that they did provide the StatelessSession. However, the DAO code has to change to use it. I think the choice of stateless or regular Session implementations should be configurable.

Nathan