Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog An Interpretation of the Source Code of OceanBase (4): Life of Transaction

An Interpretation of the Source Code of OceanBase (4): Life of Transaction

This article analyzes the external interfaces of database transactions of OceanBase.

By Zhuweng, OceanBase R&D Director

The source code is the most fundamental part of OceanBase. This series of articles focuses on the interpretation of the source code to help users understand the nature of the database. The third article of this series (Interpretation of the Source Code of OceanBase (3): Life of Partition) was about the storage layer of OceanBase. The first section was about communication protocols obmp_query but skipped the details of transaction control. The fourth article of this series introduces information about the external interfaces of transactions.

External Interfaces of Transactions

Coverage of the Transaction Layer by the Protocol Layer

The protocol layer covers the original interfaces provided by the transaction layer. The source code is located in sql/ob_sql_trans_control.h. The following screenshot shows additional information. This coverage maintains the TransState and is available for the SQL layer to call. When statements are completed, the correct transaction interface is called at a unified location according to TransState, so transaction resources are not leaked in any abnormal state.

1

Original Transaction Interfaces

Original transaction interfaces are located in the source code file storage/transaction/ob_trans_service.h. The main interface is:

  • start_trans & end_trans (please see the screenshot)
  • start_stmt & end_stmt
  • start_participant & end_participant

They correspond to the access lifecycle of transactions, statements, and participants (partitions) in statements. After the transaction is opened by the start trans, an ObTransDesc object is returned. As the only identifier of the transaction, the object is saved in the object session. It is required by other transaction interfaces and subsequent statement execution. It is also commonly used for problem diagnosis.

2

Distributed Transactions

Before the execution, the position of the leader is acquired from the location cache based on the partition information involved in the statement to select the execution plan for the corresponding category. In general, an SQL query or DML generates three types of execution plans (ObPhyPlanType ):

  • The local plan indicates that all leaders of partitions to be accessed to execute the statement are on this node.
  • The remote plan indicates that all leaders of partitions are on a remote node.
  • The distributed plan indicates that the leader of a partition is on multiple nodes.

Location cache is an important component of an overall architecture, which is used to find information about partition copies efficiently. It provides a unified interface outside but shields many distributed details. Its body implementation is located in share/partition_table (please see the screenshot). However, the source file sql/ob_sql_partition_location_cache.h covers it and unifies the processing of virtual tables.

Transaction control calls often involve a variety of factors:

  • Statement type (read-only or not)
  • Transaction type (whether to automatically commit and whether to read with weak consistency)
  • Current transaction status and type of execution plan

For example, for the local plan, the transaction commits automatically and is executed on the code in order start_trans ➡ start_stmt ➡ start_participant ➡ end_participant ➡ end_stmt ➡ end trans. For the remote plan, the transaction commits automatically. The interfaces above are all executed on the remote node. For the distributed execution plan, start/end_stmt is executed on this node while start/end_participant is executed on the node where each partition leader is located. This set of interfaces is designed to balance simplifying transaction interfaces and optimizing transaction performance by scenario.

3

This is the life of the transaction of OceanBase. The fifth article of this series explains information related to the multi-tenant architecture of OceanBase.

Database Developers Open Source source code OceanBase Transaction
0 1 0
Share on

Read previous post:

An Interpretation of the Source Code of OceanBase (3): Life of Partition

Read next post:

An Interpretation of the Source Code of OceanBase (5): Life of Tenant

OceanBase

16 posts | 0 followers

You may also like

Comments

OceanBase

16 posts | 0 followers

Related Products

More Posts by OceanBase

See All