Pools

DEPRECATED Documentation was moved into new docuemntation site

Each connection type is managed with its own PoolManager.

Default pool implementations:

• DocumentPool
• ObjectPool
• GraphPool

Pools are registered in OrientModule's configurePools() method. You can override it to register your own pool implementations.

Custom pools registration example:

public class MyOrientModule extends OrientModule {

    @Override
    protected void configurePools() {
        bindPool(ODatabaseDocumentTx.class, DocumentPool.class);
        bindPool(OObjectDatabaseTx.class, ObjectPool.class);
        bindPool(OrientGraph.class, MyCustomGraphPool.class);
        // note that for graph few entities could be provided: OrientGraph, OrientGraphNoTx, OrientBaseGraph.
        // default implementation registers additional providers to handle all cases
        // see ru.vyarus.guice.persist.orient.support.pool.GraphPoolBinder
    }
}

Default pool implementation maintains only pool for documents (using OPartitionedDatabasePoolFactory). Other pools use document connection to construct object and graph connection objects. This merges different connections transactions (change in one connection type will be visible in all others).

OGlobalConfiguration.DB_POOL_MAX used as max pools size (for OPartitionedDatabasePoolFactory).

Connection may be acquired from pool only inside unit of work. Connection object is bound to thread local inside pool, returning always the same instance during transaction.

Actual orient transaction is started only when connection object is obtained from pool.

Separate connection transactions

Before v3, each pool manage its own connection, as a result transactions were different for all connection types and changes were not visible between them.

Such behavior is still possible: write new pool implementations and register them in OrientModule.

TransactionManager supports multiple transactions out of the box (legacy behavior).

Note: PoolManager's commit or rollback methods will be called on each transaction end, even if no connection where obtained from this pool. Pool must control such situation.

When explicit rollback called, transaction manager will call rollback on each pool.

When exception occurred on commit, other pools will be still committed and rollback called only on failed pool. But other pools will receive rollback call after commit and must ignore it.

If you really want to use multi-transactional approach look sources for 2.x brach.