Menu
▾
▴
springframework-developer
|
From: Rob R. <rob...@ur...> - 2004-02-09 20:24:52
|
Regarding HibernateTemplate being threadsafe - this means that HibernateDaoSupport is threadsafe, which means that all subclasses of it (provided they themselves are threadsafe) can be marked as singleton's in the config file, right? Also, we just added an instance of TransactionInterceptor and BeanNameAutoProxyCreator, along with an instance of TransactionManager, so that we could define transaction rqmts for each business object. I assume that these can be singleton's as well, and the thread-safe business objects (manager-style) which the interceptor is applied to can thus be singleton's too? Rob ---- On Mon, 09 Feb 2004, Colin Sampaleanu (col...@ex...) wrote: > I've seen somebody get burned by the fact that HibernateTemplate is > threadsafe, while JdbcTemplate is not. We probably need to document this > difference a bit better, and the probable usage scenario that results > (i.e. it's generally ok to produce one singleton HibernateTemplate in > your context and use it everywhere, whereas you probably want to create > jdbcTemplates on demand; not even setting it non-singleton in the > context is enough, since if it is fed as a dependency to another object > which is singleton, and that object is assumed to be thread safe, there > will be problems). > > Will add some stuff to the javadocs tonight... > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > |
|
From: Colin S. <col...@ex...> - 2004-02-09 21:06:44
|
First of all, my statement about JdbcTemplate being non-threadsafe seems to be BS. I always thought it was threadsafe, but then somebody here got hit with an error from JBoss that a connection was already closed. I looked at the source, but not well enough, and assumed it was not threadsafe. Aside from the parameters which are set once at creation, there is actually nothing in there which needs to be touched once it is created, and the DataSource and connection obtained from it is attached to the current thread and transaction, so there is no problem with coming in to the same jdbctemplate instance from another thread. Now there _does_ appear to be a problem in JBoss with managing connections in a mixed Spring/EJB environment. I am still trying to track this down. It seems to be worse in 3.2.2RC3 than 3.2.3, which leads me to believe it's a JBoss bug. As for HibernateTemplate being threadsafe; yes, it's threadsafe, and so is HibernateDaoSupport and any subclasses, unless of course you add something which is not threadsafe. Same goes for HibernateInterceptor, and the TransactionInterceptors. We run everything as singletons... Regards, Colin Rob Rudin wrote: >Regarding HibernateTemplate being threadsafe - this means that >HibernateDaoSupport is threadsafe, which means that all >subclasses of it (provided they themselves are threadsafe) can >be marked as singleton's in the config file, right? > >Also, we just added an instance of TransactionInterceptor and >BeanNameAutoProxyCreator, along with an instance of >TransactionManager, so that we could define transaction rqmts >for each business object. I assume that these can be singleton's >as well, and the thread-safe business objects (manager-style) >which the interceptor is applied to can thus be singleton's >too? > >Rob > > > > > >---- On Mon, 09 Feb 2004, Colin Sampaleanu (col...@ex...) >wrote: > > > >>I've seen somebody get burned by the fact that >> >> >HibernateTemplate is > > >>threadsafe, while JdbcTemplate is not. We probably need to >> >> >document this > > >>difference a bit better, and the probable usage scenario that >> >> >results > > >>(i.e. it's generally ok to produce one singleton >> >> >HibernateTemplate in > > >>your context and use it everywhere, whereas you probably want >> >> >to create > > >>jdbcTemplates on demand; not even setting it non-singleton in >> >> >the > > >>context is enough, since if it is fed as a dependency to >> >> >another object > > >>which is singleton, and that object is assumed to be thread >> >> >safe, there > > >>will be problems). >> >>Will add some stuff to the javadocs tonight... >> >> >> >>------------------------------------------------------- >>The SF.Net email is sponsored by EclipseCon 2004 >>Premiere Conference on Open Tools Development and Integration >>See the breadth of Eclipse activity. February 3-5 in Anaheim, >> >> >CA. > > >>http://www.eclipsecon.org/osdn >>_______________________________________________ >>Springframework-developer mailing list >>Spr...@li... >> >> >> >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > >> >> |
|
From: Rod J. <rod...@in...> - 2004-02-09 22:02:32
|
I normally make DAOs threadsafe: seldom find reason to do otherwise. So yes, they should be singletons. TransactionInterceptor/TransactionManager etc normally should be singletons, as with the advised POJOs. Advisors and pointcuts in general can be shared, or per-proxy instance. So if you use a singleton tx interceptor (as you should) that will be shared for all AOP proxies. If you have a stateful advice such as a mixin, that would be unique to each proxy instance created using it. ----- Original Message ----- From: "Rob Rudin" <rob...@ur...> To: "Colin Sampaleanu" <spr...@li...> Sent: Monday, February 09, 2004 8:24 PM Subject: Re: [Springframework-developer] Threadsafe HibernateTemplate vs. non-threadsafe JdbcTemplate > Regarding HibernateTemplate being threadsafe - this means that > HibernateDaoSupport is threadsafe, which means that all > subclasses of it (provided they themselves are threadsafe) can > be marked as singleton's in the config file, right? > > Also, we just added an instance of TransactionInterceptor and > BeanNameAutoProxyCreator, along with an instance of > TransactionManager, so that we could define transaction rqmts > for each business object. I assume that these can be singleton's > as well, and the thread-safe business objects (manager-style) > which the interceptor is applied to can thus be singleton's > too? > > Rob > > > > > > ---- On Mon, 09 Feb 2004, Colin Sampaleanu (col...@ex...) > wrote: > > > I've seen somebody get burned by the fact that > HibernateTemplate is > > threadsafe, while JdbcTemplate is not. We probably need to > document this > > difference a bit better, and the probable usage scenario that > results > > (i.e. it's generally ok to produce one singleton > HibernateTemplate in > > your context and use it everywhere, whereas you probably want > to create > > jdbcTemplates on demand; not even setting it non-singleton in > the > > context is enough, since if it is fed as a dependency to > another object > > which is singleton, and that object is assumed to be thread > safe, there > > will be problems). > > > > Will add some stuff to the javadocs tonight... > > > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by EclipseCon 2004 > > Premiere Conference on Open Tools Development and Integration > > See the breadth of Eclipse activity. February 3-5 in Anaheim, > CA. > > http://www.eclipsecon.org/osdn > > _______________________________________________ > > Springframework-developer mailing list > > Spr...@li... > > > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by EclipseCon 2004 > Premiere Conference on Open Tools Development and Integration > See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. > http://www.eclipsecon.org/osdn > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > |
