Currently, if we're not in a transaction, and we do a WT_CURSOR->insert, or any one of several modifying cursor APIs, a transaction will be created (in __wt_txn_autocommit_check). At the end of the API call, if there is one of these "autocommit" transactions and a rollback error has occurred, the transaction is rolled back and the entire API call is redone. Note that the checking and retries occur in TXN_API_END (called via CURSOR_UPDATE_API).  It's pretty nifty, the application gets retries for free.

However, we now have the possibility that simple read operations like WT_CURSOR->search can return WT_ROLLBACK due to an unfortunate collision with eviction. I think there has been various fallout that we've corrected by adding application retries. But maybe we should use the same philosophy that we're currently using for modifiable operations, to have a retry of an API operation that fails due to rollback.