Clojure JIRA

Clojure JIRA http://dev.clojure.org/jira This file is an XML representation of an issue en-us

4.4

649

25-07-2011

[JDBC-11] Transaction not rolled back on Throwable exception http://dev.clojure.org/jira/browse/JDBC-11 java.jdbc <p>(transaction<br/> (insert-values .....)<br/> (throw (Throwable. "baaaaad")))</p> <p>Reported by Sebastián Galkin on github.</p> <p>Transactions rollback on Exception but not Throwable.</p> JDBC-11

Transaction not rolled back on Throwable exception

Defect Major Resolved Completed Sean Corfield Sean Corfield Sun, 3 Jul 2011 21:54:06 -0500 Sun, 17 Jul 2011 03:29:00 -0500 Sun, 17 Jul 2011 03:28:58 -0500 1 1 <p>I think the correct behavior would be to call rollback on the transaction and not just not calling commit? The user will expect at the end of the transaction block one of commit or rollback to be called.</p> <p>I was thinking about how to test this. How do you feel about a mock Connection object, where we can check if commit and/or rollback have been called as part of the test?</p> <p>The same mechanism could be used to test other features.</p> <p>I was thinking in something like the attached for testing the issue (and other functionality).<br/> It needs several improvements, but it's enough to get the idea.<br/> What do you think?</p> <p>FYI, here's the IRC discussion about this, for the record:</p> <p><span class="error">[5:11pm]</span> <paraseba><br/> In clojure.java.jdbc there is a transaction function, which is supposed to rollback if the passed body throws an exception, but it only does that in case of an Exception, not any Throwable. What's the rationale behind this?<br/> <span class="error">[5:11pm]</span> <paraseba><br/> I'd want my transaction rolledback in case of any errors<br/> <span class="error">[5:12pm]</span> <paraseba><br/> seancorfield: maybe you can explain me this?<br/> <span class="error">[5:53pm]</span> <amalloy><br/> paraseba: catching Errors is generally a bad practice. i'm not saying it's wrong all the time, but Errors are often unrecoverable anyway<br/> <span class="error">[5:53pm]</span> <amalloy><br/> eg, "You ran out of heap space! I can't even allocate memory to throw an exception!"<br/> <span class="error">[5:54pm]</span> <paraseba><br/> but, even in the worst conditions, shouldn't we try to rollback the transaction? is not better that commiting in this unexpected error condition?<br/> <span class="error">[5:55pm]</span> <paraseba><br/> we can then rethrow the Throwable, after trying to rollback<br/> <span class="error">[5:55pm]</span> <lucian><br/> paraseba: i don't think the db will commit if it gives you an error<br/> <span class="error">[5:55pm]</span> <lucian><br/> and as amalloy, errors like OOM are best solved with exit()<br/> <span class="error">[5:55pm]</span> <paraseba><br/> lucian: it will ... jdbc is catching Exception and rolling back in that case .... but it commits in a finally<br/> <span class="error">[5:56pm]</span> <paraseba><br/> so, if you have an Error thrown, it will commit<br/> <span class="error">[5:56pm]</span> <paraseba><br/> I guess that's more surprising than a rollback<br/> <span class="error">[5:57pm]</span> <paraseba><br/> the logic is .... (try do-your-thing (catch Exception roll-back) (finally commit))<br/> <span class="error">[5:57pm]</span> <lucian><br/> paraseba: well, then maybe you don't want to commit in finally?<br/> <span class="error">[5:57pm]</span> <paraseba><br/> I don't, not if I got an Error<br/> <span class="error">[5:58pm]</span> <amalloy><br/> lucian: i think he's upset that a library he's using is committing on error<br/> <span class="error">[5:59pm]</span> <paraseba><br/> amalloy: I can solve it easily by wrapping my operations in a catch Throwable -> rollback -> rethrow, but I think it's not the right behavior for the library<br/> <span class="error">[5:59pm]</span> <paraseba><br/> I would expect a commit only if the block ended without any kind of exceptions or errors. don't you agree ?<br/> <span class="error">[6:01pm]</span> <amalloy><br/> paraseba: meh. all kinds of weird stuff can happen if an Error occurs; i wouldn't be entirely certain that an attempt to "recover" makes things worse due to some weird program state caused by the Error. i mean, my completely-unresearched opinion is that catching Throwable would be better, but you can't really rely for your program's correctness on anything that happens after an Error<br/> <span class="error">[6:02pm]</span> <paraseba><br/> but, we are forcing a commit after an Error<br/> <span class="error">[6:04pm]</span> <paraseba><br/> the usual logic should be .... (do do-your-thing (commit)) if do-your-thing throws anything ... no commit is done. Puting a commit in a finally enforces the commit, even after Errors<br/> <span class="error">[6:06pm]</span> <amalloy><br/> yeah, i think i agree<br/> <span class="error">[6:08pm]</span> <paraseba><br/> amalloy: ok, I'll report an issue, thanks</p> <p>It's important to realize that there are 2 problems here.</p> <p>a.- Transaction not rolled back on Throwable<br/> b.- The original Exception is "swallowed" and a new, different one is thrown</p> <p>I think both are equally serious.</p> <p>I agree Sebastian. I've raised this issue for input from clojure-dev (looking for stylistic guidelines for contrib libraries) because I think both problems need to be fixed.</p> <p>My current leaning is toward supporting three paths:</p> <ul> <li>success: rollback transaction if user code sets rollback true, else commit</li> <li>Exception: rollback transaction and rethrow (without wrapping)</li> <li>Throwable: allow it to escape, take no action</li> </ul> <p>I'm attaching a patch that fixes the problem without adding any tests.</p> <p>On success, commit unless rollback has been set (in which case rollback).<br/> On Exception, rollback and rethrow as-is.<br/> On Error (Throwable), allow it to escape.<br/> In all cases, set rollback false and restore auto-commit setting.</p> <p>The only two changes here should be:</p> <ul> <li>Exception is no longer wrapped when thrown (may break code that expected the wrapping?)</li> <li>No commit attempted on Error (Throwable)</li> </ul> Global Rank