Seize the deal!
Caching Best Practices
Imagine having a tool that can automatically detect if you are using JPA and Hibernate properly. Hypersistence Optimizer is that tool!
In this article, I’m going to show you how to get the current database transaction id. The transaction id is very useful for logging, especially if you want to correlate multiple log entries that are executed within the context of the same database transaction.
As I explained in this article, in a relational database, transactions are mandatory. Even if you don’t declare a database transaction, you are still going to use one.
The only thing you configure is the transaction scope. So, if you don’t declare the transaction boundaries explicitly, the every SQL statement is going to be executed in its own database transaction, meaning that you are going to use the auto-commit mode.
However, most often, a business use case requires executing multiple SQL statements, in which case the auto-commit mode will prevent the database from being able to roll back all the statements executed in the context of the current running business use case.
For this reason, service layer methods are annotated with the
So, when executing a
@Transactional method, all the SQL statements executed in the context of the current business use case are going to share the same database transaction.
You can get the database transaction identifier from the database using a database-specific SQL query.
When using Oracle, you have to execute the following SQL query:
SELECT RAWTOHEX(tx.xid) FROM v$transaction tx JOIN v$session s ON tx.ses_addr = s.saddr
v$transaction view provides information about the currently running database transactions. However, there can be multiple transactions running in our system, and that’s why we are joining the
v$transaction with the
v$session view offers information about our current session or database connection. By matching the session address between the
v$session views, we can find the current running transaction identifier given by the
xid column in the
xid column is of type
RAW, we are using
RAWTOHEX to convert the transaction identifier binary value to its hexadecimal representation.
Oracle assigns a transaction identifier only if it needs to assign an undo segment, which implies that an INSERT, UPDATE or DELETE DML statement has been executed.
So, read-only transactions will not have a transaction identifier assigned. For more details about the undo log, check out this article.
When using SQL Server, you just have to execute the following SQL query:
SELECT CONVERT(VARCHAR, CURRENT_TRANSACTION_ID())
CURRENT_TRANSACTION_ID function returns a
BIGINT column value, we are using
CONVERT to get its String representation.
When using PostgreSQL Server, you can execute the following SQL query to get the current transaction id:
SELECT CAST(txid_current() AS text)
txid_current function returns a
BIGINT column value, we are using
CAST to get its String representation.
When using MySQL or MariaDB, you can execute the following SQL query to get the current transaction id:
SELECT tx.trx_id FROM information_schema.innodb_trx tx WHERE tx.trx_mysql_thread_id = connection_id()
innodb_trx view in the
information_schema catalog provides information about the currently running database transactions. Since there can be multiple transactions running in our system, we need to filter the transaction rows by matching the session or database connection identifier with the currently running session.
Just like it was the case with Oracle, since MySQL 5.6, only read-write transactions will get a transaction identifier.
Because assigning a transaction id has a given overhead, read-only transactions skip this process. For more details, check out this article.
This read-only transaction optimization works the same way in MariaDB, meaning that a transaction id is only assigned for read-write transactions only.
When using the HyperSQL database, you can execute the following SQL query to get the current transaction id:
If you enjoyed this article, I bet you are going to love my upcoming Online Workshops!
- Caching Best Practices with JPA and Hibernate (2.5 hours) on the 30th of September
- High-Performance SQL (4 hours) on the 6th of October in collaboration with Voxxed Days Ticino
- High-Performance SQL (12 hours) starting on the 28th of October in collaboration with Bouvet
Getting the current database transaction id comes in handy, especially if you want to log this info for every executed SQL statement.
Hypersistence Optimizer 2.2 has been released!