On 7/12/07, Dale Newfield <[EMAIL PROTECTED]> wrote:
Michael Horwitz wrote:
> Any chance your action calls two managers and passes in an object
> obtained from the first manager to the second?
Yes, but since I use OpenSessionInViewFilter, they're all part of a
single session and should still be valid, correct?
Correct, as long as Hibernate is not closing the session along with the
transaction. Check that/make sure that
hibernate.transaction.auto_close_session is set to false. it should be, but
you never know.....
> Also just to check that it is the same transaction interceptor that
> intercepts both methods (i.e. you don't have a customized tx
> interceptor on the second method invocation)?
Good suggestion, but no--they're both the generic txAdvice one. The
only two I've got are userManagerTxAdvice and txAdvice, as in appfuse svn.
> Could you also post a snippet as to how you go about obtaining a session
> in the relevant DAO's? It could be the DAO's are explicitly opening a
> new session rather than re-using an existing one.
They all extend BaseDaoHibernate (which extends HibernateDaoSupport),
and nothing overrides setSessionFactory
I'm assuming you are using HibernateTemplate to execute all Hibernate
actions? If teh sessionFactory is ever used to get the session, it should be
sessionFactory.getCurrentSession() and not sessionFactory.getSession()?
I do notice that some bean definitions explicitly set the sessionFactory:
<!-- Transaction manager for a single Hibernate SessionFactory
(alternative to JTA) -->
<bean id="transactionManager"
class="org.springframework.orm.hibernate3.HibernateTransactionManager">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
<!-- Generic Dao - can be used when doing standard CRUD -->
<bean id="dao" class="com.myclient.dao.hibernate.BaseDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
<!-- LookupDao: Hibernate implementation -->
<bean id="lookupDao"
class="com.myclient.dao.hibernate.LookupDaoHibernate">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
<!-- UserDao: Hibernate implementation -->
<bean id="userDao" class="com.myclient.dao.hibernate.UserDaoHibernate
">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
<!-- RoleDao: Hibernate implementation -->
<bean id="roleDao" class="com.myclient.dao.hibernate.RoleDaoHibernate
">
<property name="sessionFactory" ref="sessionFactory"/>
</bean>
while the rest just assume it'll get wired up correctly by autowire...
<bean id="fooDao"
class="com.myclient.dao.hibernate.FooDaoHibernate" autowire="byName"/>
Any reason not to make all of those autowire byName?
Sessions/transactions on all of these daos and managers work, as long as
I don't call a method on one manager from within a method on another.
Not an issue which way it is done - I assume its explicit in AppFuse just to
make it a little easier for end users - if they change the name of the
session factory, for instance, things will break quickly and with an error
message that is meaningful.
Yes--I would claim that the most annoying problems with software in
> general are when something "should" work, but doesn't. :-)
>
> Yup - agreed! And 90% of the time it usually boils down to a
> typo/ommission on my side :-)
Are you saying this is *your* fault? And here I was blaming myself! If
I buy you a beer can you fix it? I'm close to giving up and going back
to a "managers only call daos" policy, as I've just about run out of
ideas. (If for no other reason that I want to get these tasks completed
and checked in before heading out of town for a vacation! :-)
Understood! Would be good to understand what is going on here though - if it
is a bug, it should be fixed. Always up for a beer (or three...) :-)
Mike.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
