[Springframework-developer] Re: Lazy transaction creation

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

Thanks!  I will definitely be testing this out tomorrow.

Will you be taking a look at SPR-574 soon?  The SPR is to create a 
TransactionAutoProxyCreator that would make setting up simple 
transaction management scenarios much simpler.

http://opensource.atlassian.com/projects/spring/browse/SPR-574

The reason I ask is that your solution is certainly simple and elegant, 
but I think it has a drawback: it is yet another bean that must be 
defined in the application context.  Sure, one more definition isn't a 
big deal, but if you're using Spring's declarative transaction 
management, you need to setup quite a few bean definitions, many of 
which have quite sensible defaults (i.e. - the ones in the reference 
documentation).

A nice feature of your new LazyConnectionDataSourceProxy is that it's 
not a significant performance hit to use a TransactionAutoProxyCreator. 
  That's because if there's more than one transactional resource in the 
application context, beans that are autoproxied won't start up 
transactions for each resource... they'll only start up transactions 
when they are actually needed.  One of your comments to SPR-572 was, 
"Wow, that's a pretty extreme case - open transactions for 10 databases 
for each operation!  :-)"  Well with a TransactionAutoProxyCreator it's 
not an extreme case... we'll get significant savings if multiple 
databases are defined in the application context and are autoproxied, 
but don't require distributed transactions.  For simple usage of 
multiple databases (e.g. - reporting on information in multiple DBs), 
this solution will work like a champ without significant performance 
penalties :)

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