title: Why is it recommended not to close a MongoDB connection anywhere in Node.js code?
body: <p>Consider following is the Node.js code:</p>
  
  <pre><code>function My_function1(_params) {
      db.once('open', function (err){
       //Do some task 1
  });
  }
  
  function My_function2(_params) {
      db.once('open', function (err){
       //Do some task 2
  });
  }
  </code></pre>
  
  <p>See the link for best practice, which says not to close any connections</p>
  
  <p><a href="https://groups.google.com/forum/#!topic/node-mongodb-native/5cPt84TUsVg">https://groups.google.com/forum/#!topic/node-mongodb-native/5cPt84TUsVg</a></p>
  
  <p>I have seen log file contains following data:</p>
  
  <pre><code>Fri Jan 18 11:00:03 Trying to start Windows service 'MongoDB'
  Fri Jan 18 11:00:03 Service running
  Fri Jan 18 11:00:03 [initandlisten] MongoDB starting : pid=1592 port=27017 dbpath=\data\db\ 64-bit host=AMOL-KULKARNI
  Fri Jan 18 11:00:03 [initandlisten] db version v2.2.1, pdfile version 4.5
  Fri Jan 18 11:00:03 [initandlisten] git version: d6...e0685521b8bc7b98fd1fab8cfeb5ae
  Fri Jan 18 11:00:03 [initandlisten] build info: windows sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1') BOOST_LIB_VERSION=1_49
  Fri Jan 18 11:00:03 [initandlisten] options: { config: "c:\mongodb\mongod.cfg", logpath: "c:\mongodb\log\mongo.log", service: true }
  Fri Jan 18 11:00:03 [initandlisten] journal dir=/data/db/journal
  Fri Jan 18 11:00:03 [initandlisten] recover begin
  Fri Jan 18 11:00:04 [initandlisten] recover lsn: 6624179
  Fri Jan 18 11:00:04 [initandlisten] recover /data/db/journal/j._0
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:59343 &lt; lsn:6624179
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:118828 &lt; lsn:6624179
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:238138 &lt; lsn:6624179
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:835658 &lt; lsn:6624179
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:955218 &lt; lsn:6624179
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3467218 &lt; lsn:6624179
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3526418 &lt; lsn:6624179
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3646154 &lt; lsn:6624179
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section seq:3705844 &lt; lsn:6624179
  Fri Jan 18 11:00:04 [initandlisten] recover skipping application of section more...
  Fri Jan 18 11:00:05 [initandlisten] recover cleaning up
  Fri Jan 18 11:00:05 [initandlisten] removeJournalFiles
  Fri Jan 18 11:00:05 [initandlisten] recover done
  Fri Jan 18 11:00:10 [initandlisten] query MYDB.system.namespaces query: { options.temp: { $in: [ true, 1 ] } } ntoreturn:0 ntoskip:0 nscanned:5 keyUpdates:0  nreturned:0 reslen:20 577ms
  Fri Jan 18 11:00:10 [initandlisten] waiting for connections on port 27017
  Fri Jan 18 11:00:10 [websvr] admin web console waiting for connections on port 28017
  Fri Jan 18 11:01:10 [PeriodicTask::Runner] task: WriteBackManager::cleaner took: 32ms
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50076 #1 (1 connection now open)
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50077 #2 (2 connections now open)
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50078 #3 (3 connections now open)
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50079 #4 (4 connections now open)
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50080 #5 (5 connections now open)
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50081 #6 (6 connections now open)
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50082 #7 (7 connections now open)
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50083 #8 (8 connections now open)
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50084 #9 (9 connections now open)
  Fri Jan 18 13:36:27 [initandlisten] connection accepted from 192.168.0.1:50085 #10 (10 connections now open)
  ...........................................
  Fri Jan 18 13:36:48 [initandlisten] connection accepted from 192.168.0.1:50092 #97 (97 connections now open)
  </code></pre>
  
  <p>Doesn't this create a overhead on server by opening multiple connection and not closing it, Does it handles connection pooling internally?</p>
  
  <p>But in <a href="http://docs.mongodb.org/manual/faq/developers/#why-does-mongodb-log-so-many-connection-accepted-events">MongoDB Docs</a> it is mentioned "This is normal behavior for applications that do not use request pooling"</p>
  
  <p>Can somebody help me understanding this.</p>