La mgo.Session est sans danger pour une utilisation simultanée. Citant son doc :
Toutes les méthodes Session sont sécurisées pour la concurrence et peuvent être appelées à partir de plusieurs goroutines.
Mais cela ne signifie pas que vous ne devriez pas en créer et en utiliser plusieurs en parallèle, en appelant Session.Copy() ou Session.Clone() , sur la session initiale obtenue au moment de la numérotation.
La sécurité de la concurrence et l'avantage d'en utiliser davantage ne s'excluent pas (ils ne sont pas mutuellement exclusifs ). Bien que vous puissiez utiliser un seul mgo.Session à partir d'un nombre arbitraire de goroutines, qui ne s'adapteront pas bien, qui ne s'adapteront pas du tout . Les sessions gèrent automatiquement un pool de connexions, peut-être même vers plusieurs nœuds de serveur, mais si vous utilisez une seule Session , vous n'en profitez pas. En créant une nouvelle Session au début de chacune de vos requêtes (si besoin), et en la fermant proprement à la fin (avec Session.Close(); de préférence appelé en utilisant defer ), vous tirez parti de l'utilisation potentielle de plusieurs connexions en même temps, éventuellement vers plusieurs nœuds de serveur (le cas échéant), et utilisez ainsi mieux les ressources du serveur ; et obtenir des temps de réponse plus rapides (à la fois de la base de données et, en fin de compte, pour vos utilisateurs finaux HTTP). Appel de Session.Close() ne ferme pas la connexion sous-jacente au serveur, il remettra simplement la connexion dans le pool, prête à être récupérée par une autre session.
Voir également la question connexe sur l'utilisation de Session s:mgo - les performances des requêtes semblent constamment lentes (500-650 ms)
