Closed dreampuf closed 6 years ago
and a view
User = new Model("User")
app.post "/reg/", (req, res)->
u = req.body
User.put u, ()-> # it print "Segmentation fault" and exit
res.redirect "/"
Mmm...you really don't want to be using this. BDB was a failed experiment of integrating with node - I can go into the details of why it's not really tenable if you care, but suffice it to say, I'd recommend you move along - I should probably just nuke this whole repo.
@mcavage I'd be interested in hearing about why your experiment failed. I'm looking for a lightweight db I can embed in an app, and at least at first glance bdb seems like a nice way to go. What are your thoughts, as someone who has been down the road I'm considering going down?
Hi,
Yeah it does seem ideal. Here's the (short-form) catch: BDB assumes you have explicit control over threads. You don't have that in node.
Long-form: With BDB, you basically are off the reservation 99% of the time if you're not using it in "TDS" mode (i.e., transactionally). BDB has a restriction that a transaction can't span threads. In node, you have no visibility into "routing" on the EIO thread pool, so when you hand some "put/get/del" operation off to node, you're almost guaranteed to not be on the same thread you ran on before (e.g., where you did txn_begin()).
Now, there are two possible answers to this (probably more, but these are the obvious two that came to my mind): 1) You maintain your own thread pool behind the node EIO pool, and when node hands you a BDB request, you have to context-switch again, and track what handle goes to what thread. You'd have to introduce queuing there since it would always be possible to have one thread have multiple TXNs open at a time. This sucks, although I think it's actually what erlang's bdb binding does, as erlang has similar (lack of) control over threading.
2) You don't allow txn with a bunch of APIs, and only allow something like a batchPut (that is, transaction begin, operations, commit all happen on the same thread, because the thread never relinquished control). This is what I started prototyping before I abandoned ship. While I'm sure you can make this work, it felt too limiting (i.e.,, if I want to do a write based on something I read in the transaction, there's really a way to enable that).
So mostly, it just doesn't "fit". I'd probably look at leveldb as the sanest alternative here, but it doesn't have the transactions api, which is not always what you need.
The thing I was going to use this for, I just did on postgres, and colocated the node process(es) with the postgres daemon.
m
Wow. Until just now I was naively under the impression that node.js was single-threaded. You learn something new every day! Thanks for the info.
Cannot install No milestone No one is assigned Package appears to be removed from npm.
jay@ubuntu:/var/www/jayplayswithbdb$ sudo npm install bdb [sudo] password for jay: npm http GET https://registry.npmjs.org/bdb npm http 404 https://registry.npmjs.org/bdb npm ERR! 404 'bdb' is not in the npm registry.
why?
Hello @mcavage
Reading the discussions here, I believe you are saying this library didn't work out as expected. Am I corrent?
If this is the case, maybe we can elaborate on in the readme or something
I write a view, Get the data from a request.body and put it in a bdb inside. but when i call bdb_db.put , it just print "Segmentation fault", I can run the node-bdb testcase.