-
Notifications
You must be signed in to change notification settings - Fork 5
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
5 changed files
with
34 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
--- | ||
title: "Transactions" | ||
--- | ||
|
||
Transactions in databases refer to logical units of work that consist of one or more database operations. A transaction is a sequence of database operations, such as reads (queries) and writes (updates or inserts), that are treated as a single indivisible and consistent unit. The main purpose of transactions is to ensure data integrity and maintain the ACID (Atomicity, Consistency, Isolation, Durability) properties of the database. | ||
|
||
## Read-only transactions | ||
|
||
RisingWave supports read-only transactions, where all reads within a transaction are executed against the consistent Hummock snapshot. Hummock is the LSM-Tree-based storage engine in RisingWave that is specifically optimized for streaming workloads. | ||
|
||
To initiate a transaction, use either the `START TRANSACTION READ ONLY` or `BEGIN READ ONLY` command. Subsequently, you can execute queries to read data from the consistent snapshot. To finalize the transaction and submit the queries as a single unit, use the `COMMIT` command. | ||
|
||
Please note that data modifications are not allowed while a transaction is initiated but not yet committed. The statements listed below are not allowed within a transaction: | ||
|
||
- All DDL statements (`CREATE`, `ALTER`, and `DROP`) | ||
- Most of DML statements (`INSERT`, `UPDATE`, and `DELETE`) | ||
- Statements related to `USER`. This category may overlap with DDL statements. | ||
- All privilege-related statements, including `GRANT` and `REVOKE`. | ||
|
||
## Transactions within a CDC table | ||
|
||
When you create a table to ingest CDC streams, you can enable this feature by setting transactional to true in the `WITH` clause of the `CREATE TABLE` statement. Note that this feature is only available if you are using the native [MySQL CDC](/integrations/sources/mysql-cdc) or [PostgreSQL CDC](/integrations/sources/postgresql-cdc) connectors. | ||
|
||
For performance considerations, transactions involving changes to more than 4096 rows cannot be guaranteed. | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters