Question
· Aug 25, 2017

Is there a way to omit or skip rollback of some data changes during a transaction rollback?

Is there a way to omit or skip rollback of some data changes during a transaction rollback? Maybe some sort of "autonomous transaction"?

The issue is with error logging in transaction. For example we may have in nested calls the following structure:
TS
<some code>
<error happens>
TRO 1
<error log to database>

but if this code is in another transaction, and that rolls back we lose error data.

Is there a way to do something like
TS
<some code>
<error happens>
TRO 1

<autonomous transaction start\flag>
<error log to database>

<autonomous transaction finish\flag>

so error log will be stored anyway?

I know about journaling switch (to disable and enable journaling in process), and it also seems working when we map error data to unjournaled database, however, maybe there are other ways? 

Discussion (7)0
Log in or sign up to continue

To keep your logging data even if transaction rolled back, you should have this changes journaled. Because transaction rollback works by the journal. If it happened to be journaled, it will be rolled back anyway.

And you should remember even you disabled journaling for some database, while system journaling working well. Every change which was made during a transaction will be journaled anyway.

So, how to switch off journaling, for this particular data. 

  • CACHETEMP - you can map this data to database CACHETEMP. This database not journaled even if data changed in a transaction. But the problem is, that data here will be available until server will be stopped.
  • Switch journaling temporary off, just only when logging information should be saved. You can do it with command before save, should be placed in %OnBeforeSave method
    DO DISABLE^%NOJRN 
    and return journaling back after saving in method %OnAfterSave
    DO ENABLE^%NOJRN

If you log the error with ^%ETN (as in DO BACK^%ETN, or LOG^%ETN, or exceptionobject.Log()), the SETs to the ^ERRORS global are done with the transaction "suspended", so that it does not roll back.  In the future, we will be exposing this functionality for use in applications.  These get recorded in the journal so that they are recovered upon a system crash or restored in a journal restore, but they are omitted from rollback.  As others have said, ^%NOJRN is not the answer because it is ignored for mirrored databases.