Je suis actuellement en train d'utiliser un singleton sur mon application Web afin qu'il n'y ait toujours qu'une seule connexion à la base de données.
Je veux savoir si c'est une bonne idée parce que maintenant, je rencontre actuellement cette erreur:
Timetout expiré. La période de délai d'attente s'est écoulée avant d'obtenir une connexion de la piscine. Cela peut avoir eu lieu car toutes les connexions groupées étaient utilisées et la taille maximale de la piscine a été atteinte. Un autre point important est que mon site Web est actuellement en dev et pas beaucoup de gens y vont donc Je ne comprends pas pourquoi je reçois cette erreur! Voici le code de mon singleton: merci pour votre aide!
4 Réponses :
Non, c'est une mauvaise idée. Vous utilisez la mise en commun de la connexion.
N'aurait pas pu me le mettre mieux moi-même. :-P
Une explication aurait été belle.
Ah Downvotes, je t'aime. Ne jamais abandonner! @Robert: Je n'ai pas expliqué plus loin comme il y a de meilleures réponses que j'ai suscité :)
L'utilisation d'une seule connexion est une idée extrêmement mauvaise - si l'accès à la connexion est correctement verrouillé, cela signifie que ASP.NET ne peut servir qu'un utilisateur à la fois, ce qui limitera sérieusement la capacité de votre application à se développer.
Si la connexion est pas correctement verrouillée, les choses peuvent être vraiment bizarres. Par exemple, un thread peut disposer de la connexion pendant que un autre thread tente d'exécuter une commande contre elle.
Au lieu d'utiliser une seule connexion, vous devez simplement créer de nouveaux objets de connexion lorsque vous en avez besoin, pour tirer parti de la mise en commun de la connexion.
Connection La mise en commun est Le comportement par défaut des classes SQLClient (et Probablement d'autres fournisseurs de données). Lorsque vous utilisez la mise en commun de la connexion, chaque fois que vous «créez» une connexion, la connexion sera réellement tirée d'un pool de celles existantes afin que vous n'abumiez pas les coûts de la construction d'un de zéro à chaque fois. Lorsque vous le relâchez (fermez-le ou jetez-le), vous le retournez au pool de connexion, en conservant votre nombre total de connexions relativement bas.
Edit: Vous verrez l'erreur que vous mentionnez ( la période de délai d'attente écoulée avant d'obtenir une connexion à partir de la piscine ) si vous ne fermez pas (ou n'en disposant) vos connexions. Assurez-vous de le faire dès que vous avez terminé d'utiliser chaque connexion.
Il existe plusieurs questions de dépassement de bonnes piles qui discutent de cela, ce que je soupçonne peut être utile!
Si j'accepte qu'un singleton est une mauvaise idée de SQLConnection, je ne vois aucune indication que cela se limiterait à une seule demande. Il n'y a pas de verrouillage dans le code qui empêcherait plusieurs utilisateurs de l'objet SQLConnection (qui, si quelque chose, il suffit de pire une idée en raison de problèmes de filetage).
@Mark, d'oh! J'ai écrit que sans lire dans tout le code, en supposant qu'il y avait un verrouillage restreint l'utilisation de la connexion! Comme vous le note, cela peut provoquer une classe de problèmes complète. J'ai mis à jour ma réponse pour refléter cela.
Merci les gars! Réponse très rapide et claire. Il sera facile de résoudre ce problème! Merci beaucoup encore!
La raison pour laquelle utiliser une connexion à la base de données en tant que singleton est une idée horrible, c'est que chaque 2ème connexion devra attendre que la première connexion soit libérée.
Un singleton signifie qu'il n'y a qu'un seul objet de connexion de base de données, de vous connecter à la DB. Donc, si une deuxième personne veut se connecter à cela, ils doivent attendre qu'ils puissent accéder à cet objet.
C'est une mauvaise nouvelle.
Continuez simplement à créer de nouvelles instances de l'objet de connexion de base de données, au besoin. L'astuce ici consiste à ouvrir la connexion aussi tard possible, puis fermez cette connexion dès que possible.
L'opération la plus coûteuse dans un objet de connexion de base de données est la connexion . pas la création.
Pas besoin d'un singleton. Voici quelques articles sur la mise en commun de la connexion:
.NET 1.1
Connexion Footfering pour le fournisseur de données .NET Framework Pour SQL Server
Utilisation de la communication de la connexion avec SQL Server