|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were seeing errors in xapian_create_job that indicated that the
current transaction had been aborted but not rolled-back. It seems
that this happened because sometimes xapian_create_job was called
from within another transaction (e.g. from the transaction block in
AdminIncomingMessageController#redeliver). The default behaviour
of nested transactions in Rails is for them to behave as if all
but the outermost transaction blocks had no effect; this means
that the exception thrown in the inner transaction block in
xapian_create_job wasn't causing a rollback, and it was then being
caught before propagating up to the outermost transaction. Thus
the transaction was never being rolled-back so any subsequent
operation on this database connection would error.
This commit fixes this problem by using the :requires_new => true
option to transaction, which asks ActiveRecord to fake genuinely
nested transcations using SAVEPOINT.
Fixes #1124.
|