open a leveldb handle multiple times, transparently upgrading to use multilevel when more than 1 process try to use the same leveldb data directory at once and re-electing a new master when the primary unix socket goes down
Normally with level, when you try to open a database handle from more than one process you will get a locking error:
events.js:72throw er; // Unhandled 'error' event^OpenError: IO error: lock /home/substack/projects/level-party/example/data/LOCK: Resource temporarily unavailableat /home/substack/projects/level-party/node_modules/level/node_modules/level-packager/node_modules/levelup/lib/levelup.js:114:34
With level-party, the database open will automatically drop down to using multilevel over a unix socket using metadata placed into the level data directory transparently.
This means that if you have 2 programs, 1 that gets:
var level = ;var db = ;;
and 1 that puts:
var level = ;var db = ;var n = Math;;
and you start them up in any order, everything will just work! No more
IO error: lock exceptions.
$ node put.js & sleep 0.2; node put.js & sleep 0.2; node put.js & sleep 0.2; node put.js & sleep 0.2 3498 3502 3509 3513$ node get.jsa= 35340a= 31575a= 37639a= 58874a= 35341a= 31576$ node get.jsa= 35344a= 31579a= 37643a= 58878a= 35345^C
level-party does seamless failover. This means that if you create a read-stream and the leader goes down while you are reading that stream level-party will resume your stream on the new leader.
This disables leveldb snapshotting so if your app relies on this you should disable this by setting
opts.retry = false
var db = // will not retry streams / gets / puts if the leader goes down
level-party works on windows as well using named pipes.
var level =
The arguments are exactly the same as level. You will sometimes get a real leveldb handle and sometimes get a multilevel handle back in the response.
With npm do:
npm install level-party