Objects of the Transaction
class are created by DbClient
, and many transaction-related operations are performed automatically:
- At the beginning of the
Transaction
object creation, the begin statement is automatically executed tostart
the transaction; - If there is an exception that causes the transaction to fail, the
rollback
statement is automatically executed to roll back the transaction; - If the transaction has been rolled back, then the sql statement will return an exception (throw an exception or perform an exception callback);
The method of transaction creation is provided by DbClient
as follows:
This interface is very simple, it returns a smart pointer to a object. Obviously, when the smart pointer loses all the holders and destructs the transaction object, the transaction ends. The parameter commitCallback
is used to return whether the transaction commit is successful. It should be noted that this callback is only used to indicate whether the commit
command is successful. If the transaction is automatically or manually rolled back during execution, the callback
will not be executed. Generally, the commit
command will succeed,the bool type parameter of this callback is true. Only some special cases, such as the connection disconnection during the commit process, will cause the commitCallback
to notify the user that the commit fails, at this time, the state of the transaction on the server is not certain, the user needs to deal with this situation specially. Of course, considering that this situation rarely occurs, with non-critical services the user can choose to ignore this event by ignoring the commitCallback
parameter when creating the transaction (The default empty callback will be passed to the newTransaction method).
The framework also provides an asynchronous interface for creating transactions, as follows:
This interface returns the transaction object through the callback function, does not block the current thread, and ensures high concurrency of the application. Users can use it or the synchronous version according to the actual situation.
The interface is almost identical to DbClient
, except for the following two differences:
- The user cannot call the transaction’s
newTransaction()
interface, which is easy to understand. Although the database has the concept of a sub-transaction, the framework does not currently support it.
The framework currently does not provide an interface to control transaction isolation levels, that is, the isolation level is the default level of the current database service.
The smart pointer of the transaction object is held by the user. When it has unexecuted sql, the framework will hold it, so don’t worry about the transaction object being destructed when there is still unexecuted sql. In addition, the transaction object smart pointer is often caught and used in the result callback of one of its interfaces. This is the normal way to use, don’t worry that the circular reference will cause the transaction object to never be destroyed, because the framework will help the user break the circular reference automatically.
For the simplest example, suppose there is a task table from which the user selects an unprocessed task and changes it to the state being processed. To prevent concurrent race conditions, we use the Transaction
class, the program is as follows: