On on., 2015-12-09 at 08:16 -0800, John Wagenleitner wrote: > On Wed, Dec 9, 2015 at 6:20 AM, Alexander Holand Salgado > <[email protected]> wrote: > > Hi, > > > It seems that groovy.sql.Sql's cacheConnection {} and > withTransaction {} > both close the used connection on returning, regardless of the > surrounding context, and if using a data source the currently > used > connection is set to NULL. E.g. if you do: > > sql.cacheConnection { cc -> > > sql.withTransaction { tc -> /* tc is same object as cc */ > > } > > /* connection closed/null here */ > } > > You'll get an error if trying to execute any database queries > using the > cc-connection after the withTransaction closure. > Also, for the same reason, you cannot have nested > cacheConnection {} > closures (if you wanted to for some reason). > > Looking at the source code for these methods it seems that > they both > purposely ignore the current cacheConnection state during > resource > clean-up and therefore end up closing/nulling the connection > regardless > of context. > > To me this seems incorrect - am I missing something here? > > > > > > > I don't think you're missing something, those methods don't look like > they were designed to be nested (with each other or themselves). If > nesting were allowed, it doesn't seem like the following could be > handled correctly for both datasource and single connection backed > instances. > > > > withTransaction (or cacheConnection) { > > insert A... > withTransaction { > insert B... > } > // both A and B are committed > }
Thanks for confirming my suspicion. Yes, nested withTransaction would not provide the results you might first think you'd get and should probably not be allowed. But, I'm still thinking that its worth looking at supporting nesting withTransaction within a cacheConnection as this should be fine - but that might be something for the dev mailinglist.(?)
