Menu
▾
▴
[Springframework-developer] Re: Lazy transaction creation
|
From: Matt S. <sga...@us...> - 2005-01-13 12:16:24
|
Ah-hah... I missed that. Thanks, Matt Juergen Hoeller wrote: > 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 > > > > ------------------------------------------------------- > 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 |
