This topic describes the transaction specifications of OceanBase Database.
OceanBase Database 3.x does not impose a size limit on large transactions. However, you must control the number of concurrent transactions to prevent memory usage from surging.
The number of parameters in the IN clause of the WHERE clause is no longer limited.
When the memory usage of MemStore reaches 80% during the initialization of an OBServer node, the writing speed is throttled:
alter system set writing_throttling_trigger_percentage = 80 TENANT = ALL;
Notice
Throttling will limit the replay speed of clogs, which may affect the timing of a dump trigger.
When you perform batch data operations, the program must have the ability to handle interruptions and a transaction failure retry mechanism.
OceanBase Database implements distributed transactions using two-phase commit. Therefore, transactions must have a failure retry mechanism and a way to check the status of pending transactions.
Except for the
set namesstatement, no other set statements, such asset timezone,set SQL_mode, andset isolation_level, can be used in the frontend program.When you need a unique primary key, sequences are very useful. Sequences can provide globally unique and continuous integers.
Limit the number of concurrent sessions.
If a tenant has n CPUs, it usually has up to
10*nactive user sessions. Any additional concurrent sessions will wait for an available worker thread before becoming active.Enable automatic commit transactions. We recommend that you use the
Connection.setAutoCommit(xx)interface instead of executingset @@autocommit=xx.Enable transactions. We recommend that you use the
Connection.setAutoCommit(xx)interface instead of executingstart transaction/begin.Complete transactions. We recommend that you use the
Connection.commit()／Connection.rollback()interface instead of executingcommit/rollback.