[Springframework-developer] Re: Lazy transaction creation

[Matt S. <sga...@us...>]

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