I've read over #122 and the commit referenced in the issue. Using a separate database connection on a model to create records that are not affected by the transaction rollback is definitely a nice workaround. However, SQLite does not support concurrent connections, so the second database connection hangs while the transaction is still pending and the transaction never gets committed because it's waiting for the after_failure callback to return, yielding this exception: SQLite3::BusyException: database is locked: commit transaction.
It would be nice to break the after_failure callback out of the transaction or to at least have that as an option.
I've read over #122 and the commit referenced in the issue. Using a separate database connection on a model to create records that are not affected by the transaction rollback is definitely a nice workaround. However, SQLite does not support concurrent connections, so the second database connection hangs while the transaction is still pending and the transaction never gets committed because it's waiting for the after_failure callback to return, yielding this exception:
SQLite3::BusyException: database is locked: commit transaction.It would be nice to break the after_failure callback out of the transaction or to at least have that as an option.