Menu
▾
▴
Re: [Springframework-developer] Re: Lazy transaction creation
|
From: Juergen H. <ju...@in...> - 2005-01-12 08:11:39
|
Lazy connection check added. If the eager check on startup fails, the first transaction on that DataSource will fetch a physical JDBC Connection on getAutoCommit and getTransactionIsolation to retrieve the actual defaults, keeping those default values from then on to be able to expose them without fetching a physical Connection. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Juergen Hoeller Sent: Wednesday, January 12, 2005 8:46 AM To: spr...@li... Subject: Re: [Springframework-developer] Re: Lazy transaction creation 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 _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
