Transactions

The IDO runtime service automatically executes all UpdateCollection requests in a transaction. It also executes IDO methods in a transaction if they are marked as “transactional” methods. All other IDO requests are executed without a transaction. Be aware that, if a method is not marked “transactional” and is called from a method that is marked “transactional”, then it still executes in the caller's transaction.

For transactional IDO methods, if the method returns an integer value less than 5, the transaction is committed. The exception is if the method was executed within an existing outer transaction. Then the transaction commits only if and when the outer transaction commits. If the IDO method returns an integer value greater than or equal to 5 the transaction is rolled back immediately. The Mongoose standard is to return 16 to indicate a method failed. The transaction also rolls back if the method throws an exception.

If you need more control over transaction scope, which is often necessary for long-running processes, you can achieve this while still allowing the IDO runtime service to manage transactions.

For example, consider a method that posts a large batch of records. You need a method that reads the batch, loops through each record, and attempts to post it. If the post is successful, the action commits, otherwise it rolls back. The best way to accomplish this is to create two methods: a top level entry point method that queries the records to be posted; and another method to do the posting. The top-level method should not be marked as transactional, while the posting is transactional. The entry point method queries the records to be posted and loops through each one, calling the posting method to post each record. This way, if a record fails to post, it does not roll back all posted records, only the failed record.