OrientDB 2.1.x Transaction/Concurrency Compatibility

[Johannes Schüth]

OrientDB's transaction handling requires some workarounds to be applied in order to be used in combination with Ferma.

• OrientGraph instances are not threadsafe.
• A new transaction has to be created for each thread.
• OrientDB Elements (eg.: OrientVertex) are not threafsafe. Thus the element has to be reloaded when switching threads of passing a ferma element from one thread to another.

I created my own vertex frame which internally deals with some of those requirements:

public class OrientVertexFrame extends AbstractVertexFrame {

    private Object id;
        // ThreadLocal which will hold the base element reference for each thread and 
       // reload the element if required.
    public ThreadLocal<Element> threadLocalElement = ThreadLocal.withInitial(() -> ((WrappedVertex)getGraph().getVertex(id)).getBaseElement());

        // ThreadLocal which will hold the current active graph (eg.: Transaction)
    public static ThreadLocal<FramedGraph> threadLocalGraph = new ThreadLocal<>();

    @Override
    protected void init(FramedGraph graph, Element element) {
        super.init(graph, element);
        this.id = element.getId();
    }

    @Override
    public Vertex getElement() {
        Element vertex = threadLocalElement.get();

        // Unwrap wrapped vertices
        if (vertex instanceof WrappedElement) {
            vertex = (Vertex) ((WrappedElement) vertex).getBaseElement();
        }
        return (Vertex)vertex;
    }

    @Override
    public FramedGraph getGraph() {
        return new DelegatingFramedGraph<>(threadLocalGraph.get(), true, false);
    }
}

Transactions should set the thread local and restore it within the duration of the transaction. I created an autoclosable which handles those transactions and updates to the threadlocal.

[Johannes Schüth]

I create a small extension library which provides some abstract classes and other useful stuff when dealing with transactions in ferma + orientdb.

The project currently is just a collection of tests and classes. I have no plan to release it. It can be used as a reference when using orientb with ferma.

https://github.com/Jotschi/ferma-orientdb-extension

[Jeffrey Phillips Freeman]

Do you think this is something that might be useful as a part of Ferma? I
will have to take a closer look at it.

On Sat, Oct 17, 2015 at 2:46 PM, Johannes Schüth [e-mail]
wrote:

I create a small extension library which provides some abstract classes
and other useful stuff when dealing with transactions in ferma + orientdb.

The project currently is just a collection of tests and classes. I have no
plan to release it. It can be used as a reference when using orientb with
ferma.

https://github.com/Jotschi/ferma-orientdb-extension

—
Reply to this email directly or view it on GitHub
#10 (comment).

[Johannes Schüth]

I'm not sure. The only ferma specific parts are AbstractDelegatingFramedOrientGraph, AbstractInterceptingEdgeFrame and AbstractInterceptingVertexFrame. Those classes just tweak the default behavior of ferma to allow transaction handling and element creation in oder to provide orientdb types. (related to question: https://groups.google.com/a/syncleus.com/forum/#!topic/ferma-list/NfGw2KjqC4I)
So far i have not added a type resolver that will make use of the orientdb types. (I also have no plans to do so since i'm using the *explicit methods as much as possible)

[Johannes Schüth]

But i would welcome vendor specific submodules for ferma.

[Jeffrey Phillips Freeman]

I too would love to see vendor specific submodules.. so if we can get it to
a point that is useful and clean id be happy to make it part of the project.

On Sat, Oct 17, 2015 at 3:05 PM, Johannes Schüth [e-mail]
wrote:

But i would welcome vendor specific submodules for ferma.

—
Reply to this email directly or view it on GitHub
#10 (comment).

[Johannes Schüth]

We now have an OrientDB specific module for ferma which handles the vendor specific transactions. I think we can close the issue.