Need a method to close/unlock the database

[GoogleCodeExporter]

The LevelDB object should have a method to release the lock on the database.
Currently it seems like the only way to close the database is to delete every 
reference to it so it is garbage collected.

Original issue reported on code.google.com by m...@whoosh.ca on 23 May 2013 at 9:20

[GoogleCodeExporter]

The implementation might be tricky. I release the Python GIL for all DB 
operations, so a naive implementation might close the database in the middle of 
an operation.

Not releasing it serializes DB operations, so you can add the necessary 
safeguards.

One idea I had to add a close() operation, was basically to set a flag, and 
then do a wait until all running DB operations are done. In the interim you 
would disallow all new DB operations.

If it helps I do keep track of objects referencing the main DB object (e.g. 
snapshots and iterators), which is easy to expose.

Original comment by arnim...@gmail.com on 23 May 2013 at 10:47

[GoogleCodeExporter]

If it helps, my problem is that I want to have multiple processes accessing the 
same database. Obviously I need to serialize their access, but there's no way 
(I can see) to get the first process to give up the db and let other processes 
use it.

Original comment by m...@whoosh.ca on 23 May 2013 at 11:17

[GoogleCodeExporter]

Ok, I think I understand.

The pattern I describe is the simplest approach I've found so far. You just 
need to keep track of the count all live objects and live operations. A number 
which, when zero, indicates that it is safe to close the DB.

close() would then block until that number reaches zero, and then close the DB. 
Perhaps a timeout would also be in order?

(I'm open to other ideas)

Original comment by arnim...@gmail.com on 23 May 2013 at 11:39

• Changed state: Accepted

[GoogleCodeExporter]

Hi, is there any further progress on the `close` feature?

Thanks.

Original comment by h...@botify.com on 18 May 2015 at 10:35

[GoogleCodeExporter]

Unfortunately, no. Because of the threading issues, I felt the implementation 
would be complicated, and was a bit reluctant to pursue it.

Note that there is a very good and active fork at 
https://github.com/rjpower/py-leveldb, and a not so active (mine) at 
https://github.com/arnimarj/py-leveldb

Original comment by a...@dohop.com on 18 May 2015 at 2:26