Server side level txs #1731

laa opened this Issue Oct 5, 2013 · 4 comments


None yet

3 participants

laa commented Oct 5, 2013

This issue is more discussion than plan to do , but I thought about following,
With WAL we do not need to track txs on client side only, because we do not need to keep all the changes in memory, so no server overhead.
It gives as following:

  1. No temporary tx rids which got complains in ML, only valid ones.
  2. No memory overhead because we need to keep all tx records in memory before commit, so heap which is wasted now in tx mode and usually empty will be used for disk cache, we need really a few memory to serialize/deserialize object in case of big graphs just hundred megabytes.
  3. No problem with SQL queries in TX mode, new and updated records will not be lost.
  4. Code will be cleaner, because we simply drop good amount of code )).

Disadvantage of course is (may be ...) performance will be slower on tx server mode, it is easy to test just drop begin/commit for big set of commands, make indexes fully durable in non tx mode (we have option for this) and lets check.


lvca commented Oct 5, 2013

I think this would fix many issues but this would be closer to the RDBMS model. The goodness of OrientDB optimistic approach is that during tx no server-side resources are consumed and locked. So in theory this supports much more load. So why don't let to the user to select the tx type?

Now we've:

public interface OTransaction {
public enum TXTYPE {

We could introduce: OPTIMISTIC_CLIENTSIDE_ONLY, but let to the OPTIMISTIC (the default) to do everything at server side.

Users should know that when use OPTIMISTIC_CLIENTSIDE_ONLY any command executed at server side wouldn't work. But at this point the name OPTIMISTIC_CLIENTSIDE_ONLY is clear enough.


laa commented Oct 7, 2013

I thought about non locking transactions, when was writing this issue, when we implement this #1600 which allows achieve following features:

  1. reads do not content with writes.
  2. writes do not content with writes too.

so we can think about this cluster as about lock free collection. then we will not need to lock records for commit (actually we will not need to lock records in non-tx mode too). So this server side tx implementation is optimistic not pessimistic implementation. From my point of view pessimistic TXs should not been implemented they have very low scalability.

Also we need to implement multithreaded txs first, to prevent performance degradation.

lvca commented Oct 7, 2013


@lvca lvca modified the milestone: 2.1, 2.0 Mar 28, 2014
@lvca lvca modified the milestone: 3.0, 2.1 Feb 1, 2015
@laa laa was assigned by lvca Feb 1, 2015
@lvca lvca modified the milestone: 3.1, 3.0 Dec 4, 2015
laa commented Apr 6, 2016

Assigned to @tglman

@laa laa assigned tglman and unassigned laa Apr 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment