I haven't looked at that particular code, but I here's some explanation about some other code that sometimes needs to commit and sometimes not, and how that is handled.

The code I'm referring to is the attachment code.  There are two needs:

1) If a perform-harness is in progress and an attachment is added to the work object, then NO commit is desired, since the commit will occur as part of normal flow processing, and if the user decides to bail, a rewind is desired such that the attachment be backed out.

2) If no perform-harness is in progress, then a commit is desired so that the work object be properly updated on the db to show the attachment.

To facilitate the two needs, the attachment code has an input boolean parameter called something like do-commit, and if it's passed in as TRUE, then the commit is performed.

I would suggest you look at a similar solution.  If the activity in question is not a "final" one, you can make your own version of the activity so you can add such a parameter.  If you do so though, be careful of several things, including:

1) You may not have the flexibility to edit all the callers of the activity in order to provide the parameter a value, so design the parameter-handling such that if the parameter is not given a value, the activity behaves identically as it does today.

2) There's always a risk when you make your own version of any out-of-box rule that if a new out-of-box version f that rule is released, or a hotfix containing a change to that activity is released, either the hotfix may be inadvertantly eclipsed, or you may lose your changes, so you need to be careful whenever applying hotfixes.