Transaction commit following rollback

Question

We have code I'm maintaining where I have something like this:

<cftransaction>
    <cftry>
        ... do some stuff here which may throw an exception ...
        <cftransaction action="commit">
        <cfcatch>
            <cftransaction action="rollback">
            <cfif someCondition>
                <cfset someFunctionThatAffectsTheDB() />
                <cftransaction action="commit" />
            </cfif>
        <cfcatch>
    <cftry>
</cftransaction>

I'm a bit leery of the commit in the catch that happens after the rollback. I've searched the interwebs for info on what might happen in such a case, but haven't found anything so far that would say what would happen if you try to commit after rolling back inside the same transaction block. Does anyone know what this would do and whether it's ok to do or is a bad thing?

(The reason I ask is because we have a data state in our db that I don't think should be possible and I'm wondering if the behavior of commit-after-rollback is undefined and subtle and could cause what I'm seeing.)

Answer 1

I'm assuming your someFunctionThatAffectsTheDB() is how you log the error? If you are using Oracle then I recommend none of your stored procedures contain commits. The commit would happen when the closing cftransaction tag is reached. But for logging errors and such you would declare that stored proc as PRAGMA AUTONOMOUS_TRANSACTION; and it WOULD have a commit in it. Then you don't have to worry about using any actions="rollback or commit". We have a huge application and very rarely have ever needed to use a cftransaction to commit or rollback because we need everything to work, or everything to go back to how it was. And our error logging is the only proc needed to be PRAGMA AUTONOMOUS_TRANSACTION; If you are not using Oracle then just ignore, sorry, you didn't specify your backend.

Answer 2

Went out on a limb and asked our DBA. He indicated that the rollback would roll anything back that had been done in the db, and that any further changes at that point (like changes made by the someFunction... call) would be committed on the subsequent commit. I haven't done a boiled-down test, and it may vary by DB settings and vendor, but I think that's how it works.