We are using Couchbase Lite Java SDK 2.7 and have two stand alone JAVA processes running against the same couchbase lite db and doing writes and reads to completely different set of documentsWe are getting this error Caught SQLite exception while vacuuming: database is locked. Under what circumstances we will get this error? Is there an automatic vacuuming happening behind the scenes?
I guess you need to package your Java standalone application to allow them to use shared external libraries (CBLite Java SDK in this case). I know exactly what to do for Java web application while deploying to Tomcat, but not very sure about standalone applications.
It is packaged. The scenario is that two standalone java processes are writing into save couchbase db. We are not calling compact or vacuum any where but still somehow somewhere vacuum is getting called and since the writes are in progress the vacuum command is not able to obtain lock on the db . First of all why and who is calling vacuum, is it something in the SDK or a default behavior of couchbcase db or SQLite 3. Any help in understanding why this exception is occurring would be really appreciated.
So what is the impact of the error or are you confirming to ensure its benign? Also, can you share full stack trace?
IIRC, Couchbase Lite (as of 2.7.0) does not automatically do any vacuuming of unused rev bodies unless compact() API is explicitly called and even then, IIRC, I recall there was a bug in earlier versions that caused the compact() API to have no effect). What version of Java client are you using ? Is it 2.7.1?
Tagging @jens to see if he can shed more light on the same.
It crashes due to fatal exception. Please note the two java stand alone processing us making changes to the database concurrently but to different documents. First of all is it okay practice to have multiple processes make changes to same db ensuring documents are never in conflict?. We are using only couchbase lite and not using sync gateway or the server.
we are using 2.7.0 should we upgrade to 2.7.1 and test it out?
See below the stack trace…
CouchbaseLiteException{CouchbaseLite,16,‘database is locked’}
at com.couchbase.lite.internal.CBLStatus.convertException(CBLStatus.java:92)
at com.couchbase.lite.internal.CBLStatus.convertException(CBLStatus.java:46)
at com.couchbase.lite.AbstractDatabase.saveInTransaction(AbstractDatabase.java:1524)
at com.couchbase.lite.AbstractDatabase.saveConflicted(AbstractDatabase.java:1485)
at com.couchbase.lite.AbstractDatabase.saveInternal(AbstractDatabase.java:1445)
at com.couchbase.lite.AbstractDatabase.save(AbstractDatabase.java:395)
at com.couchbase.lite.Database.save(Database.java:30)
at com.couchbase.lite.AbstractDatabase.save(AbstractDatabase.java:379)
at com.couchbase.lite.Database.save(Database.java:30)
at gov.usda.fs.pinyon.erecords.ProcessTracker.updateInfo(ProcessTracker.java:105)
at gov.usda.fs.pinyon.erecords.event.ConsumerManagement.processEvents(ConsumerManagement.java:149)
at gov.usda.fs.pinyon.erecords.event.ConsumerManagement.process(ConsumerManagement.java:105)
at gov.usda.fs.pinyon.erecords.event.ConsumerManagement.main(ConsumerManagement.java:934)
Caused by: LiteCoreException{domain=1, code=16, msg=database is locked}
at com.couchbase.lite.LiteCoreException.throwException(LiteCoreException.java:26)
at com.couchbase.lite.internal.core.C4Document.update2(Native Method)
at com.couchbase.lite.internal.core.C4Document.lambda$update$8(C4Document.java:304)
at com.couchbase.lite.internal.core.C4Document.withHandleThrows(C4Document.java:367)
at com.couchbase.lite.internal.core.C4Document.update(C4Document.java:304)
at com.couchbase.lite.AbstractDatabase.saveInTransaction(AbstractDatabase.java:1516)
… 10 more
I do not see anything in that trace which says that compaction was causing the database to be locked . Where is that trace?
Writes are locked at file level. i.e. you can have only one writer at a time. You can have multiple readers. If you are sharing database file between multiple processes, then only one can write at a given time. It does not matter that they are updating separate documents. The onus is on the app developer/platform to ensure authorized access to the shared database file.
Let me also just warn here that Couchbase Lite was not designed to be used from multiple processes sharing the same database file, so it wouldn’t surprise me if things didn’t behave well sometimes.