Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Server side level txs #1731

Open
laa opened this Issue · 3 comments

2 participants

Andrey Lomakin Luca Garulli
Andrey Lomakin
Collaborator
laa commented

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.

WDYT ?

Luca Garulli
Owner

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 {
NOTX, OPTIMISTIC, PESSIMISTIC
}
}

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.

WDYT?

Andrey Lomakin
Collaborator
laa commented

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.

Luca Garulli
Owner

+1

Luca Garulli lvca modified the milestone: 2.1, 2.0
Luca Garulli lvca modified the milestone: 3.0, 2.1
Andrey Lomakin laa was assigned by lvca
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.