Here's the MSGPATH msg:
14:51:17 Assert Failed: Rollback error 101
14:51:17 IBM Informix Dynamic Server Version 12.10.FC6
14:51:17 Who: Session(37, user@machine, 2364, 0x44c21448)
Thread(68, sqlexec, 44be0f28, 1)
File: rstrans.c Line: 3278
14:51:17 Results: Log record (OLDRSAM:HINSERT) in log 58,
offset 0x4324 was not rolled back
stack trace:
afstack
afhandler
affail_interface
logundo
rlogm_undo
rsrollback
sqisrollback
sqrollback
aud_sqrollback
excommand
sq_execute
sqmain
This stack was caused by an explicit rollback work command, it
could also be some sort of save point rollback which would show
up as sprback->rssprback in place of the above rollback
functions.
When looking at onlog output you would see something like the
following:
transaction 1 does a begin work and creates a partition for the
logged temp table and does some work into the temp table, it
would then log CLR records to rollback everything including the
create of the partition. At that point the transaction would be
finished up with either a rollback work or commit. Then a 2nd
different transaction would do a begin work and create a
partition that gets the same partnumber as transaction 1. It
also then does work into the logged temp table. Now another
transaction for the same session as transaction 1 would be
created and you would see it drop the partnumber that was used
by the previous that was still open. So then when/if
transaction 2 needs to rollback work, it fails because the
partition for it's temp table has been dropped by a different
session.
For this sort of thing to happen, the temp table was
created/dropped inside a stored procedure which is being
executed due to an for each row action of an insert trigger.
When the SPL is called in this way, if there's a raise exception
inside the SPL, the log records for the SPL (which would be the
create and modifications to the temp table) generate CLR records
to undo the work inside the SPL. At that point the transaction
could be committed or rolled back. |
