if you're using windsor, you have to make absolutely sure that every transient component resolved through Windsor is released explicitly (through the container's Release method).
Transient dependencies of transient resolved components will be disposed of immediately once the resolved component is released through the container. If you don't do that, they will actually never be disposed and will remain in memory forever. On Fri, Jan 1, 2010 at 8:48 PM, Jan Limpens <[email protected]> wrote: > Yes, exactly. But in this case nh and rhino commons should manage this - > and I assume they do this correctly. > > So my suspicion is, that some transient services holding a reference to an > ISession, do not get disposed as quickly as I would want them to (Castle > Windsor contains them) and thus clobber up the connection pool. But this is > all theory. > > What would be interesting for me to know is how you guys would debug such a > situation. > > 2009/12/31 <[email protected]> > > Sounds like dispose/close is not being called on a session somewhere. I >> have had the same error when not closing ado.net connections in the >> past... >> >> Sent from my Verizon Wireless BlackBerry >> ------------------------------ >> *From: * Jan Limpens <[email protected]> >> *Date: *Wed, 30 Dec 2009 23:43:42 +0100 >> *To: *nhusers<[email protected]> >> *Subject: *[nhusers] how to debug a leaking connection pool (question) >> >> hello, >> >> recently under not yet clearly defined circumstances (it isn't load), we >> sometimes get into the situation of a non-reacting sql server with the >> thrown exception: >> >> Timeout expired. The timeout period elapsed prior to obtaining a >> connection from the pool. This may have occurred because all pooled >> connections were in use and max pool size was reached. >> >> In the connection string we define the pool with min 4 and max 100 - by >> the dimensions of the website suffering from this condition, this should be >> sufficient. Seems to me, something opens connections, but does not release >> them - but I have no real good idea, on how to debug this (especially as >> this shows only on the production server, as usual), to find the evil doer. >> >> Anyone could give me some hints, on how to approach this? >> >> We are using nh 2.1 with the rhino.commons base application for session >> management. >> >> -- >> Jan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<nhusers%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "nhusers" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]<nhusers%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/nhusers?hl=en. >> > > > > -- > Jan > > -- > You received this message because you are subscribed to the Google Groups > "nhusers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<nhusers%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nhusers?hl=en. > -- You received this message because you are subscribed to the Google Groups "nhusers" 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/nhusers?hl=en.
