Menu
▾
▴
Re: [Springframework-developer] Re: Lazy transaction creation
|
From: Juergen H. <ju...@in...> - 2005-01-13 09:04:32
|
The only reason for the "defaultAutoCommit()" and "defaultTransactionIsolation()" is to deliberately *avoid* the JavaBean property pattern here, as the return value does *not* match the type accepted by "setDefaultAutoCommit" and "setDefaultTransactionIsolation" (it's primitives for the setters, wrapper types for the accessors). Strictly speaking, we could still use "getDefaultAutoCommit()" and "getDefaultTransactionIsolation()", because those accessors are protected and wouldn't be detected by the JavaBeans Introspector (which just introspects public methods) anyway. However, I considered it clearer to still use different method names, indicating that those accessors are not part of the bean properties defined by "setDefaultAutoCommit" and "setDefaultTransactionIsolation". Of course, any name other than "getDefaultAutoCommit()" and "getDefaultTransactionIsolation()" would have done the job. Because those are just internal accessors to be called by LazyConnectionInvocationHandler, I didn't worry too much about it :-) Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Matt Sgarlata Sent: Thursday, January 13, 2005 5:53 AM To: spr...@li... Subject: [Springframework-developer] Re: Lazy transaction creation 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 ------------------------------------------------------- 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 |
