Transactions

Transactions

<wiki:toc max_depth="4" />

Introduction

OrientDB is an ACID compliant DBMS. By default no transaction is opened when you use Orient.

In some situations transactions can improve performance, typically in the client/server scenario. If you use an Optimistic Transaction, the OrientDB engine optimizes the network transfer between the client and server, saving both CPU and bandwidth.

Record IDs

OrientDB uses temporary RecordIDs with transaction as scope that will be transformed to finals once the transactions is successfully committed to the database. This avoid to ask for a free slot every time a client creates a record.

Fail-over

An Orient instance can fail for several reasons:

• HW problems, such as loss of power or disk error
• SW problems, such as a Operating System crash
• Application problem, such as a bug that crashes your application that is connected to the Orient engine.

You can use the OrientDB engine directly in the same process of your application. This gives superior performance due to the lac of inter-process communication. In this case, should your application crash (for any reason), the OrientDB Engine also crashes.

If you're using an OrientDB Server connected remotely, if your application crashes the engine continue to work, but any pending transaction owned by the client will be rolled back.

Auto-recovery

At start-up the OrientDB Engine checks to if it is restarting from a crash. In this case, the auto-recovery phase starts which rolls back all pending transactions.

Transaction types

No Transaction

Default mode. Each operation is executed instantly.

Calls to begin(), commit() and rollback() have no effect.

Optimistic Transaction

This mode uses the well known Multi Version Control System (MVCC) by allowing multiple reads and writes on the same records. The integrity check is made on commit. If the record has been saved by another transaction in the interim, then a OConcurrentModificationException exception will be throw. The application can choose either to repeat the transaction or abort it.

    db.open("remote:localhost:7777/petshop");
    
    try{
      db.begin(TXTYPE.OPTIMISTIC);
      ...
      // WRITE HERE YOUR TRANSACTION LOGIC
      ...
      db.commit();
    }catch( Exception e ){
      db.rollback();
    } finally{
      db.close();
    }

In Optimistic transaction new records take temporary RecordIDs to avoid to ask to the server a new RecordID every time. Temporary RecordIDs have Cluster Id -1 and Cluster Position < -1. When a new transaction begun the counter is reset to -1:-2. So if you create 3 new records you'll have:

• -1:-2
• -1:-3
• -1:-4

At commit time these record temporary RecordIDs will be converted in the final ones.

Pessimistic Transaction

This mode is not supported yet by the engine. Track issue for more information.

Improve reliability in case of hw/sw crash

By default OrientDB, uses the Operating System's capabilities to speed up access to the underlying file system.

If you have a reliable IO system such as RAID hardware device this is not a problem. But if you run OrientDB on top of non-reliable HW (no RAID controller) or you want to reduce at the minimum database integrity problems on improvise crash of the Server machine then enable a synch for each transaction log operation.

Via JVM configuration:

    java ... -Dtx.log.synch=true ...

or via API:

    OGlobalConfiguration.TX_LOG_SYNCH.setValue(true);

You can also execute a synch against every single database file once transaction commit is completed.

Via JVM configuration:

    java ... -Dtx.commit.synch=true ...

or via API:

    OGlobalConfiguration.TX_COMMIT_SYNCH.setValue(true);

Tuning

For further information look at Transaction tuning to know more.

Distributed environment

Today transactions can't be distributed across multiple servers. The transaction semantic is not guarantee if the involved records come from different server nodes.