2

Imagine you have an os process which includes several independent concurrent agents and each one of these agents will need to access the MongoDb server independently and read and write from/to it. Many of these read and writes could be to the same database and collection on the MongoDb server.

  1. How should I allow every one of these agents to create their own MongoServer, MongoDatabase, MongoCollection instances? Is it ok to have many instances of these objects in one os process? (there could be 10000 agents) Could that create any bottleneck?

  2. Everytime that an agent is making a call to the Mongo server, should I make it to get a get new instance of these objects (MongoServer, MongoDatabase, MongoCollection) or is it ok for each agent to hold on to its own instance of these object and use it for its life?

  3. Should I worry about connection pool when I have so many agents in one process aceesing the Mongo objects ?

iCode
  • 4,308
  • 10
  • 44
  • 77

1 Answers1

2

The Unit of Work discussion here Unit of work in mongodb and C# seems to draw some light on this, basically saying it doesn't really matter, unlike context objects in ORMs for example.

Community
  • 1
  • 1
Meligy
  • 35,654
  • 11
  • 85
  • 109
  • This is true for the MongoServer object but how about multiple instance of other mongo driver objects in one process? Are they gonna be affected by the shared connection pool? – iCode Feb 15 '12 at 02:48
  • I'd expect if the server is cheap, then likely everything else is cheap, especially for something like collection, you'd expect it to be only a wrapper around collection name, etc, and the query itself is always constructed dynamically. – Meligy Feb 15 '12 at 04:39