LeanXcale Concepts

LeanXcale transaction management is based on a patented radically new approach to transactional processing that is able to provide transactional data consistency while being able to scale out to large numbers.

LeanXcale achieves transparent and scalable transaction processing obeying stringent response time requirements by introducing a range of innovations:

The LeanXcale concurrency control mechanism is based on snapshot isolation, for its advantages regarding conflict avoidance compared to locking and two-phase commit based approaches.

These benefits have been well established both for traditional relational database systems as well as transaction solutions on top NoSQL databases.

All transactions in LeanXcale are atomic. Any transaction will either be performed completely, or completely rolled back to original state.

COMMIT has a cost and this is specially true if strong session consistency mode is activated.

LeanXcale has two session consistency modes:

The default consistency mode is getting control back when the commit is The commit has to be durable and all checks done, but before the commit is guaranteed to be fully completed.

This provides more efficiency, but still predictable read data consistency for a session, while also offering low latency reads and lowest possible latency writes.

Strong session consistency mode also returns before the COMMIT is guaranteed to be fully done, but before starting any new transaction it checks (and waits if needed) that the previous COMMIT is fully completed.

Both session consistency modes provide guaranteed monotonic reads, and writes and ability to read your own writes.

A lower isolation level increases the ability of many users to access the same data at the same time, but increases the number of concurrency effects (and possibly anomalies) users might encounter.

Conversely, a higher isolation level reduces the types of concurrency effects that users may encounter, but requires more system resources and increases the chances that one transaction will block another.

Isolation is typically defined at database level as a property that defines how/when the changes made by one operation become visible to other,

Snapshot isolation works by creating a start and a commit timestamp for each transaction. When the transaction begins, it is assigned the start timestamp, this particular transaction will observe all versions up to start.

When the transaction ends it tries to commit and if this succeeds (there is no write conflict), it is assigned the commit timestamp.

When the transaction is committed, other transactions will be able to observe its modifications.

Using Snapshot Isolation you get a strict isolation level and for a wide array of applications it is possible to achieve a serial execution or even to fully implement serializability,

All Snapshot Isolation histories can be mapped to single-valued histories while preserving data dependencies.

Snapshot does not guarantee serialization in itself, but this is actually the point:

Imagine that we have a bag containing a mixture of white and black marbles. Suppose that we want to run two transactions. One transaction turns each of the white marbles into black marbles. The second transaction turns each of the black marbles into white marbles. If we run these transactions under serializable isolation, we must run them one at a time. The first transaction will leave a bag with marbles of only one color. After that, the second transaction will change all of these marbles to the other color. There are only two possible outcomes: a bag with only white marbles or a bag with only black marbles.

If we run these transactions under snapshot isolation, there is a third outcome that is not possible under serializable isolation. Each transaction can simultaneously take a snapshot of the bag of marbles as it exists before we make any changes. Now one transaction finds the white marbles and turns them into black marbles. At the same time, the other transactions finds the black marbles - but only those marbles that where black when we took the snapshot - not those marbles that the first transaction changed to black - and turns them into white marbles. In the end, we still have a mixed bag of marbles with some white and some black. In fact, we have precisely switched each marble.

However, this is correct. Conceptually the two transactions are: Switch white marbles into black ones and switch black marbles into white ones so this is a expected outcome if both can work in parallel and that’s what snapshot isolation enables in contrast to serialization.

Consider two transactions, P and Q. P copies the value in a register x to y, and Q copies the value in a register y to x. There are only two serial executions of these two, P, Q or Q, P. In either, the end result is that x = y. However, Snapshot Isolation allows for another outcome:

In Snapshot Isolation this is still valid - both transaction were consistent and the writes didn’t overlap - but there is still an error: x and y have been swapped.

LeanXcale supports two isolation levels: READ_COMMITTED, or Snapshot Isolation to provide read consistent view of the database to all transactions.

However, if you are used to READ_COMMITED, you may expect a different behavior when using snapshot isolation.

In LeanXcale, durability is attained through a set of distributed Logger components acting independently or in groups. This guarantees that you have logged replicas in case a machine and/or disk breaks down.

Since conflicts are managed at the row level, conflicts are very unlikely (unless there are a lot of concurrent users and there is a very specific hot spot in the data model).

However, the developer has to consider conflicts. This means that you should always handle the Abort exception in any INSERT, UPDATE or COMMIT operation and act accordingly instead of relying on the database making the session wait until the lock is released from another session and aquired by your sessipn.

An example: Let’s imagine you are building a web sales solution and have a screen where users do the final purchase reducing the stock. Next pseudo-code shows how to handle this situation with LeanXcale.

Since in SQL transactions don’t need to be explicitly started because the start is implicit when you connect or you finish (with COMMIT or ROLLBACK) the previos transaction, the first part in Java using JDBC would be:

Also, using SQL and JDBC, the Conflict is not a Explicit Exception, but a state of an SQLException:

The default behavior for LeanXcale is to defer checks.

The main drawback when deferring checks is that it is difficult to know which specific operation checks are failing and, if several are failing you just have one input.

If you need detailed information, you can configure transactions to perform checks synchronously.

Locks are used to ensure that transactions are well-formed. Locks can have different durations:

A transaction is considered well-formed if both writes and reads request a lock before performing the action on a data item or set of data items.

The standard method of doing transactions involves a two-phase method:

Locks are normally a derivation of on of two types:

Using locks that block processes, 2PL may be subject to deadlocks that result from the mutual blocking of two or more transactions.

Two major types of locks are utilized:

LeanXcale manages conflicts at the row level. When two concurrent transactions try to modify the same row, one of the transactions is aborted.

This behavior is different to a lot of other transactional databases that typically lock the rows, forcing other sessions to wait until the lock is released.

In LeanXcale, the visibility of updates is not connected to the atomic commits.

Any form of complex and time consuming coordination among components, such as a 2-phase commit protocol, is avoided.

Instead, transactions can commit fast and in parallel without compromising consistency.

The goal of serializability is to keep the data in the data item in a consistent state, and is considered a strong criterion for the correctness of a concurrent transaction schedule.

Schedules that are not serializable are likely to generate erroneous outcomes.

The idea is that if one transaction is correct by itself (and order is irrelevant), then a schedule that consists of a sequence of these transactions is correct. Therefore, if a concurrent schedule is equivalent, then it is also correct.

When starting any connection you can define the connection mode. Basically, there are 3 connection modes:

By default, all the connections will be MANUAL. If a specific client wants to connect with using a different connection mode, the client should use the property MODE with one of the accepted values (RUN, MANUAL or STRONG). This property is accepted only on JDBC connections. For other Query Engine connectors, you can just modify the default value. The defalut value can be modified in the LeanXcale configuration file. To modify the default value, please contact us on LeanXcale support team email

LeanXcale manages conflicts at the row level. When two concurrent transactions try to modify the same row, one of the transactions is aborted.

This behavior is different to a lot of other transactional databases that typically lock the rows, forcing other sessions to wait until the lock is released.

LeanXcale uses a readability concept that consists of two parts: persistency and visibility.

When the data is both Persisted and Visible, it is Readable for all other transactions.

This division allows to distribute all transaction among scalable components, because you can scale the isolation of writes and the isolation of reads in a separable way.

For more details, see the section about conflict management.