Caching is a concept that will create a copy of the database table structure providing a comfortable environment for the user applications. OrientDB has several caching mechanisms at different levels.

The following illustration gives an idea about what caching is.

In the above illustration DB1, DB2, DB3 are the three different database instances used in an application.

Level-1 cache is a Local cache which stores all the entities known by a specific session. If you have three transactions in this session, it will hold all entities used by all three transactions. This cache gets cleared when you close the session or when you perform the “clear” method. It reduces the burden of the I/O operations between the application and the database and in turn increases the performance.

Level-2 cache is a Real cache that works by using third party provider. You can have full control over the contents of the cache, i.e. you will be able to specify which entries should be removed, which ones should be stored longer and so on. It is a full shared cache among multiple threads.

Storage model is nothing but storage device that is disk, memory, or remote server.

How Cache Works in OrientDB?

OrientDB caching provides different methodologies in different environments. Caching is mainly used for faster database transactions, reducing the processing time of a transaction and increasing the performance. The following flow diagrams show how caching works in local mode and client-server mode.

Local Mode (Embedded Database)

The following flow diagram tells you how the record is in-between storage and used application in the local mode i.e., when your database server is in your localhost.

When the client application asks for a record OrientDB checks for the following −

• If a transaction has begun, then it searches inside the transaction for changed records and returns it if found.

• If the local cache is enabled and contains the requested record, then returns it.

• If at this point the record is not in cache, then asks for it to the Storage (disk, memory).

Client Server Mode (Remote Database)

The following flow diagram tells you how the record is in-between storage and used application in the client-server mode i.e., when your database server is in remote location.

When the client application asks for a record, OrientDB checks for the following −

• If a transaction has begun, then it searches inside the transaction for changed records and returns it if found.

• If the local cache is enabled and contains the requested record, then returns it.

• At this point, if the record is not in cache, then asks for it to the Server through a TCP/IP call.

• In the server, if the local cache is enabled and contains the requested record, then returns it.

• At this point, still the record is not cached in the server, then asks for it to the Storage (disk, memory).