UnQLite Users Forum

locking mechanism

append delete Johannes

Two programs (or the same program different thread) open the same database, both in ReadWrite_mode. The one is only reading, the other one tries to write a record(=exclusive lock for a second)... but receives a 'database is locked error', which appears odd to me. Only the one that actualy tries to write something should lock the database. Is that not what a shared lock is all about? I try to find more explanation on your locking mechanism, but can't find it on the internet.

Furthermore I combined your hash-system on disk with the Larry Btree ( also on disk), and it works...

Reply RSS


append delete #1. chm

can you elaborate more i.e. OS, compile directive, thread enabled, etc. Do you have any C/C++ samples for that.

You know, UnQLite rely on the locking mechanism offered by the underlying filesystem. Some of them have weird behavior and there is absolutely no way to predict it. We try everything possible to make everything consistent but sometimes odd result are expected.

One last thing, when writing to the database, an exclusive look is requested which mean that no other process (even reader) should have access to the DB expect the writer.

append delete #2. johannes

Your last sentence says it then : that is a problem. How can I use such a behaviour in an environment where a lot of people read data, and sometimes someone writes data. I can not ask all those people to leave the database while some lonesome cowboy tries to write something... can I ?
I can elaborate about the OS, but it acts just the way you explained in your last sentence.
OS=debian7-64bit , thread is enabled in UNQL, the UNQLITE is compiled as a shared library, like this :




$(objects) : $(sources)
gcc -c ${WGPDEBUG} ${envvars} $(sources)

libUnQLite: clean $(objects)
gcc -c -g -fPIC unqlite.c -o unqlite.o
gcc -shared -Wl,-soname,libUnQLite.so -o libUnQLite.so unqlite.o
sudo cp $(homedir)unqlite.h /usr/local/include/wgp/
sudo cp $(homedir)libUnQLite.so /usr/local/lib/wgp/
sudo ldconfig

rm -f *.o *.so *~
#---------- end of makefile
I understand that when someone writes to the db, that the db (or part of the db) is locked during the time it takes to re-arrange the database, but in the case of UNQLITE, some program P2 simply opens the database, and from there on my program P1 gets a 'db is locked error' when it tries to write something... unusable, because P2 only opens the database, and leaves it open, (eg for use with cursors), until that program ends. So, P2 even doesn't do anything, simply keeps the db open for further use, but even then a db locked error is the result for P1. I would program it the other way arround. Everybody may keep the database open, but when someone writes something, the db is RW-locked for a fraction of a second for the other users.

append delete #3. johannes

meanwhile I have been quickly reading your wiki on serializability, and I think that my args still stand. Hope there is a simple solution.

append delete #4. chm

The exclusive lock mechanism is the one based on SQLite. Even when you have multiple reader and someone want to write to the database. The write is put on a queue until all reader locks are relinquished. A quick solution is to enable multihreading and to work with threads instead of process but ...Anyway we'll investigate the problem and try to a concrete solution!

Thanks for using the product

append delete #5. Johannes

I like the product. With a BPtree on disk it would be a hit.

append delete #6. chm


Actually, we've working B+Tree KV storage engine available for commercial users, it should go to the public when appropriate.

append delete #7. shiva

Hallo Chm,

Adding to the above discussion,
I have enabled the Multithreading.
1. In one thread I am trying to Store different data in the Database using an array of keys. I am doing a Database commit as soon as I store any data and also closing the database between 2 stores and reopening again for any fresh operations.

2. While the Store is ongoing after some time I start my 2nd thread which Tries to Retrieve the data from this database using the same keys. I am opening the database in another handle using UNQLITE_OPEN_READONLY attribute. Now the read should happen as the Retrieves are concurrently possible. But, still I get UNQLITE_BUSY which means the database reads are not concurrent even though I have enabled the multithreading.

Sorry!! I did not provide any code sample. But, its just a serial Write and a Serial Read from 2 different threads.

append delete #8. Urs

Another Question to this topic:

Is it right that the behavior descried above is happen because the same database is open open more the once (means there different database connection handles).

Whats happen if a program with different threads open the database once and the the same database connection handle is use by the different threads accessing the database (reading writing) ?

Is this possible ?
Are the database function (UnQlite API) atomic ?


(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: chm_at_symisc, devel_at_symisc