Issue with DatabaseFactory.open(ComponentFile.MODE.READ_ONLY) - checks for active instance regardless of MODE

[glennirwin]

ArcadeDB Version:

ArcadeDB Version 23.11.1

OS and JDK Version:

PopOS(ubuntu) and JDK 21 (embedded db)

Expected behavior

Opening local database with ComponentFile.MODE.READ_ONLY should allow concurrent connection and should not lock the database

Actual behavior

The DatabaseFactory.open(ComponentFile.MODE.READ_ONLY) function looks like it calls the checkActiveInstance on the database and locks the database regardless of the MODE passed into it.

Steps to reproduce

I have a web server using ArcadeDB and when many requests come at once, even the readonly connections responding to a GET will fail must wait and retry for the database to be available.

The documentation says: If you open a database in READ_ONLY mode, no lock file is created, so the same database could be opened in READ_ONLY mode by another process at the same time. (I assuming by another process, that means another thread, right?)

But the code for the open function says:

public synchronized Database open(final ComponentFile.MODE mode) {
    checkForActiveInstance(databasePath);

    final LocalDatabase database = new LocalDatabase(databasePath, mode, contextConfiguration, security, callbacks);
    database.setAutoTransaction(autoTransaction);
    database.open();

    registerActiveInstance(database);

    return database;
  }

Am I doing this wrong?

[lvca]

We keep one instance in RAM that is shared among all the threads in the same JVM. This is true no matter the mode you open the database. In read-only mode, we don't lock the files, so multiple processes can open the same files.

What's the issue with the current behavior? Too long wait at database open or you're not able to use your database from other threads/processes?

[glennirwin]

Opening in READ_ONLY mode failed on a embedded database while another thread had the database open.

I have switched to embedded server mode and the problem is gone. Embedded server mode is nice and fast and has no issues with my web server getting hammered by many users at once in testing with JMeter.