Menu
▾
▴
[Springframework-developer] Re: Lazy transaction creation
|
From: Matt S. <sga...@us...> - 2005-01-13 04:52:55
|
The destroy-method fix is working for me in the nightly. For what it's worth, I have a number of post processors and some AOP running too and everything looks like it's working great in the nightly :) Thanks for the fix! In LazyConnectionDataSourceProxy, how come you have defaultAutoCommit() and defaultTransactionIsolation() methods instead of getDefaultAutoCommit() and getDefaultTransactionIsolation()? That really threw me through a loop because Spring made me start exposing EVERYTHING as getter/setter pairs. Maybe I went overboard? ;) Matt Juergen Hoeller wrote: > Matt, > > Regarding the issue with custom destroy methods: Indeed, the bean factory > looks for them on the exposed object rather than the originally defined one; > in your case, on the LazyConnectionDataSourceProxy instead of on the wrapped > BasicDataSource. > > This is not deliberate but rather an unfortunate side effect. I've just > adapted AbstractAutowireCapableBeanFactory to detect this scenario and > register the original bean objects as disposable beans (implementing > DisposableBean or having defined a destroy-method) if necessary. The > mechanism was already there, because of a similar problem with inner beans. > I'll commit the change today; please give the next nightly snapshot a try if > you have the chance! > > I'll also add lazy defaultAutoCommit/defaultTransactionIsolation checks to > LazyConnectionDataSourceProxy, kicking in when the check on startup failed. > Note that you can also specify those defaults as bean properties: In that > case, no check of a Connection will happen, as we assume that the specified > defaults match those of the target DataSource. > > Juergen > > > -----Original Message----- > From: spr...@li... > [mailto:spr...@li...]On Behalf > Of Matt Sgarlata > Sent: Wednesday, January 12, 2005 1:31 AM > To: spr...@li... > Subject: [Springframework-developer] Re: Lazy transaction creation > > > Juergen - > > The LazyConnectionDataSourceProxy works great :) I am using a > BeanNameAutoProxyCreator to automatically apply transaction management > to all of my Struts Actions, yet the Actions don't fail even if the > actual database is not working, so long as they don't touch the database :) > > One comment - I would suggest adding the ability for defaultAutoCommit > and the defaultTransactionIsolation to be lazily fetched. I'm guessing > you're doing an eager fetch in the afterPropertiesSet method so that > only a single connection need be retrieved when the context is refreshed > rather than one connection when defaultAutoCommit is lazily fetched and > a separate one when defaultTransactionIsolation is lazily fetched. I > think it would be best to have *both* your eager strategy and a lazy > strategy available as a backup in case the eager strategy fails. That > way, if the DB is down when the application starts up but comes on line > later, the defaultAutoCommit and defaultTransactionIsolation will still > get set correctly. > > I set up the LazyConnectionDataSourceProxy in the > postProcessAfterInitialization method of a BeanPostProcessor (as > suggested in the JavaDoc). However, when I refresh my application > context I'm getting errors: > > ERROR (DefaultListableBeanFactory:invokeCustomDestroyMethod) - Couldn't > find a destroy method named 'close' on bean with name 'carlosPool' > ERROR (DefaultListableBeanFactory:invokeCustomDestroyMethod) - Couldn't > find a destroy method named 'close' on bean with name 'dev2Pool' > ERROR (DefaultListableBeanFactory:invokeCustomDestroyMethod) - Couldn't > find a destroy method named 'close' on bean with name 'devDatabasePool' > > Obviously the problem is that the ApplicationContext is attempting to > call the close method of the LazyConnectionDataSourceProxy instead of > the close method of my underlying > org.apache.commons.dbcp.BasicDataSource. Is this considered a feature? > I would think it would be better for the close method of the unproxied > class to be invoked rather than the close method of the wrapper object > created by the BeanPostProcessor. > > Matt > > Juergen Hoeller wrote: > >>Guys, >> >>Please check out the following issue that I've just addressed: >> >>http://opensource.atlassian.com/projects/spring/browse/SPR-572 >> >>As I said in my comment, I've been wondering about this for a while and >>finally took the occasion to implement a generic solution for it. A >>particularly nice side effect is that it allows for efficient > > transactional > >>reads with HibernateTransactionManager, avoiding database communication >>overhead if everything can be resolved in the second-level cache! >> >>I'll commit this in a moment, so feel free to give it a try. >> >>Juergen >> >> >> >>------------------------------------------------------- >>The SF.Net email is sponsored by: Beat the post-holiday blues >>Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. >>It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Springframework-developer mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt |
