ObjectDB ObjectDB

lockfiles in client/server mode


i have an objectdb server running on localhost as user "objectdb", spawned like so:

java -server -cp /usr/local/share/objectdb/objectdb.jar: com.objectdb.Server -conf /etc/objectdb/objectdb.conf start

it has naturally created and taken ownership of /tmp/ObjectDB.

problem: i cannot run a maven test with my own account, or deploy a working webapp running as the tomcat user. for whatever reason the client is attempting to create lockfiles in /tmp/ObjectDB. my account and the tomcat account naturally cannot do this on the same machine where the objectdb server has done it.

a persistence unit is defined in src/main/webapp/META-INF/persistence.xml with a jdbc URL that looks to me as though it ought to connect to the server rather than attempt to start in embedded mode. i have also tried creating the EMF with the explicit URL. when running `mvn test`, the exception is:

        at com.objectdb.o.RCL.<clinit>(RCL.java:33)


Caused by: com.objectdb.o.UserException: Failed to create a new file '/tmp/ObjectDB/objectdb/1504562258.lck'


Caused by: java.io.FileNotFoundException: /tmp/ObjectDB/objectdb/1504562258.lck (Permission denied)


have i misconfigured something?

edit: i should note that changing temp= in /etc/objectdb/objectdb.conf does not help. for example,

<temp path="$objectdb/work" threshold="64mb" />


lrwxrwxrwx 1 root staff      24 Apr  5 16:44 work -> /var/local/objectdb/work


drwxr-sr-x 3 objectdb objectdb 4096 Apr  5 16:45 objectdb


drwxr-xr-x 3 objectdb objectdb 4096 Apr  5 16:45 ObjectDB

it seems to not care about the <temp> setting, and creates lockfiles in both locations. so i still cannot start the client in an unconfigured state that would use /tmp.


Your description indicates a collision of the server and the client that try using the same directory for their temporary files.

Changing the temporary directory path on the client side should solve the problem, so maybe the configuration file that you have edited is not the one that is in use. Try inserting a deliberate XML error to the file, if the client starts this configuration file is probably not used (see rules for the configuration path on this manual page).

A better solution could be changing the permissions of the temporary directory (/tmp/ObjectDB) in a way that it will be accessible by both the server and the client.

Finally, if you can post the complete stack trace of the exception (at least the ObjectDB code lines) it may help improving ObjectDB, and maybe it would be possible to avoid this collision in similar cases by changing the way that ObjectDB uses temporary files.


ObjectDB Support

thank you for the quick reply!

for the time being i have decided to run tomcat, objectdb server and maven tests with my user account, and this has been successful since the ID numbers the lockfiles are generated with are highly unlikely to collide.

changing the temporary directory on the server should have prevented it from creating and using /tmp/ObjectDB at all; i think this is a bug in its own right since that one server process created both that directory and the "$objectdb/work" directory which i had put in the config file, and created lockfiles in both (i don't know what for: /var/local/object/db/ never had any databases in it under those conditions). should i submit an issue ticket for this?


Build 2.3.7_14 should fix both issues:

  • A temporary directory will not be created in the default location if you change the temporary path in the configuration file to another path.
  • Client / server permission collision in handling temporary files should be avoided now.

Thank you for this report.

ObjectDB Support


To post on this website please sign in.