Thanks - I see your slides already mentioned this very pitfall ;) I think the problem with the examples you've posted there is that you are creating a domain for every query() call and also having to remember to wrap the callback in bind() or intercept(). That's too much of a burden for every call - particularly when the official node docs imply that one simply has to create a domain during the early stage of an incoming request and from then on exceptions will be caught properly.
I'm not a node expert but I can't help but wonder if domains would be easier to use if they simply stayed in place across all callbacks and didn't have this notion of 'owning' EventEmitters. That way all you would need to do is install a domain and never have to worry about whether your pooled resources are going to dump you into a different domain at some point. Maybe this would only work if node were to maintain a stack of domains - I'm not sure of the implications of that. I realise I'm probably missing something important here ;) Either what I'm suggesting wouldn't work or couldn't be easily implemented. I see there's another discussion going on on this list about node modules that seem to be alternatives to domains (or are they built on domains somehow?), On Monday, 12 November 2012 23:56:42 UTC, Forrest L Norvell wrote: > > On Monday, November 12, 2012 at 3:36 PM, pie_lard wrote: > > Cool - thanks! > > This definitely could be better documented. It's a pretty easy trap to > fall into. > > Also, your solution still depends on process.domain which isn't mentioned > officially (ie. at http://nodejs.org/api/process.html ). > > For that, I was just following your lead. I think the intent is > that process.domain is meant to be used by library writers who want to make > use of domains without directly depending on node 0.8+. There's also > domain.active, for code that's built to be domain-aware from the get-go. > > However, my assumption is that the typical domain pattern is going to look > a lot more like: > > var domain = require('domain'); > // setup... > > app.get('/thinger/:doer', function (req, res) { > var d = domain.create(); > d.on('error', function (error) { /* oh no */ }); > d.run(function () { > // do a buncha stuff > db.query("SELECT * FROM foo WHERE ?", params, d.bind(function (err, rows, > cols) { > // handle > }); > }) > } > > or, more succinctly (using domain.intercept, which is documented, but not > with any particularly convincing motivation): > > var domain = require('domain'); > // setup... > > app.get('/thinger/:doer', function (req, res) { > var d = domain.create(); > d.on('error', function (error) { /* oh no */ }); > d.run(function () { > // do a buncha stuff > db.query("SELECT * FROM foo WHERE ?", params, d.intercept(function (rows, > cols) { > // handle > }); > }) > } > > > I gave a little talk on domains last week, and my slides are here: > http://othiym23.github.com/domainion/ > > It's my first cut at this material and tries to put all this in context, > and might help you figure out what's going on a little better. > > F > > Forrest L Norvell > Node.js agent engineer > | E [email protected] <javascript:> | C (415) 823-6356 | T > @othiym23<http://twitter.com/othiym23> > | G github.com/othiym23 | W newrelic.com > *(* *(* **)**)* *New Relic* > > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
