0

My assumption on xodus database locking was that closing the entity store would close the database.

I implemented this with a simple example using the use pattern that calls close:

package whatever

import jetbrains.exodus.entitystore.Entity
import kotlinx.dnq.XdEntity
import kotlinx.dnq.XdModel
import kotlinx.dnq.XdNaturalEntityType
import kotlinx.dnq.store.container.StaticStoreContainer
import kotlinx.dnq.util.initMetaData
import kotlinx.dnq.xdRequiredStringProp
import org.junit.Test
import java.nio.file.Files

class UnclosedTest {
    private val dbFolder = Files.createTempDirectory(null).toFile()

    private val store = StaticStoreContainer.init(
            dbFolder = dbFolder,
            environmentName = "store"
    ).also {
        XdModel.registerNodes(
                Bogus
        )

        initMetaData(XdModel.hierarchy, it)
    }

    @Test
    fun `lock file is removed when store is closed`() {
        store.use { store ->
            store.transactional {
                Bogus.new {
                    text = "gnarf"
                }
            }
        }

        assert(dbFolder.exists())
        assert(dbFolder.isDirectory)
        assert(!dbFolder.resolve("xd.lck").exists())
    }

    class Bogus(entity: Entity) : XdEntity(entity) {
        companion object : XdNaturalEntityType<Bogus>()

        var text by xdRequiredStringProp()
    }
}

Surprisingly, this test fails with the xd.lck file still being present.

How do I close all resources, making sure the lockfile is removed?

mritz_p
  • 3,008
  • 3
  • 28
  • 40
  • As mentioned by @vyacheslav-lukianov the `lck` file is never removed (although my solution is to manually remove it it is not the correct way) it's just the only possible way I can think of now since serializing the environment does not work https://stackoverflow.com/questions/59168655/serializing-the-xodus-environment-object – quarks Sep 08 '20 at 01:38

1 Answers1

2

The xd.lck file is being released on closing the database, not removed, regardless of which API do you use: Environments, EntityStores, or Xodus-DNQ DSL. See how it is implemented.

Vyacheslav Lukianov
  • 1,913
  • 8
  • 12
  • It does not release when the application was not able to have a graceful shutdown, https://stackoverflow.com/questions/63786000/removing-lock-on-non-graceful-application-shutdown – quarks Sep 08 '20 at 01:29
  • What do you mean by "was not able to have a graceful shutdown". Is the JVM still running? – Vyacheslav Lukianov Sep 08 '20 at 12:35
  • For instance, the server was shutdown/rebooted unexpectedly when the app runs again it won't be able to access Xodus as it will throw that lock issue, the workaround is to remove the lock manually through the command line, the obvious downside you have to be on guard for scenarios like system rebooting or worst servlet container spawning new process (instance) of the application or merely respawning the process since it will have a new Process ID, that's bad news to the app, as it will be getting the exception. – quarks Sep 08 '20 at 13:20
  • An obvious workaround would be to cache the `Environment` object off-heap, but, this class is not serialization so it's kind of a dead-end unless there's another workaround. See: https://stackoverflow.com/questions/63791360/caching-objects-with-ehcache – quarks Sep 08 '20 at 13:21
  • The lock is being released when the JVM exits, expectedly or unexpectedly. The contents of the lock file is not a constraint itself, it just FYI. If the JVM keeps running and it has an instance of open database (Environment/EntityStore/VFS), no command line tool could help to release ther lock. – Vyacheslav Lukianov Sep 08 '20 at 14:58
  • It can be removed when the app is not running anymore that is what I meant. Here's a scenario, app is running then the server shutdown unexpectedly, trying to run the app would result in an exception in Xodus because the `.lck` file is still there, so you have to remote it manually before you can bootstrap the app again. – quarks Sep 08 '20 at 16:43
  • Existense of the lock file doesn't prevent an app to open the database. My answer above is short but comprehensive: there is no need to remove the lock file. – Vyacheslav Lukianov Sep 09 '20 at 06:53