Run service requests from a failed deliver operation
We are modifying the Build On Deliver code:
http://jorgediazblog.wordpress.com/2013/01/24/rtc-build-on-deliver-participant/
To better suit our needs. One case is that we want to do the build request even if the deliver fails.
Surprisingly, when this happens, although the build seems to be requested successfully, this operation doesn't get "committed".
The IBuildRequest UUID object returned from this request doesn't exist, and we never see a new build queueing up.
It looks like all operations done (including calling other service, like ITeamBuildRequest) are never "committed" (or are being rolled back) if the operation fails. Is this intentional behavior? Is there a way to override it?
|
One answer
|
Replying to myself:
If you ever need to "commit" a change from inside a transaction context, independent if the transaction succeeds or not, you can use ITransactionService#executeTaskAfterCurrentOutermostTransaction(), and implement a AbstractPostOutermostTransactionTask that does whatever you want to commit. It will be done after the transaction finishes.
This reply has more information about it: https://jazz.net/forum/questions/32947/handling-long-running-asynchronous-jobs-on-rtc-server.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
To my knowledge, as long as an operation fails, everything rolls back. Otherwise, you will get partially commits and you will consider it as "broken".
Is there a way to override this behaviour?