Out of connections... or am I?

I'm getting the classic message "The timeout period elapsed prior to obtaining a connection from the pool" etc when connecting to my SQL Server 2005 Express from a .Net application.
Then I try connecting, simultaneously, from a simple ASP.net thing I wrote just for testing and this works fine. So, then the connection pool can't be full, can it? Or, does each application have its own pool??The application has its own pool. I have run into this before. Check through the .net application to make sure you closed all the connections.|||Check through the .net application to make sure you closed all the connections.I thought .Net did all this for you?|||From what I've understood, the Garbage Collector closes connections, but it might take some while before it does it. And I'm not sure that it can take care of all the relevant connections.

About my problem; it seems to work now after having changed the application to log in as an other user. Could it have been caused by some other error in the user/login setup?|||I imagine the Garbage Collector will close connections after the application exits, but when does a web application exit? The connections are sitting in the pool, and the close connection is what releases the connection back to the pool to be used again. Another annoying thing to note is that a connection is only reusable by other connection objects only if they share the same connection string. I think under ADO differences in the order of attributes made for two separate connection pools, but I am not sure, now.|||I noticed now that as soon as I re-save the config file read by IIS for this application, the application removes all the sleeping connections and it works fine, until a 100 connections limit is reached again. (Increasing the 100 threshold would just postpone the problem.)
Killing all the processes from within SQL Server doesn't help.|||what I learned from my brief stint as a java programmer was to never trust the garbage collectors and to always DIY. people poke fun at me for explicitly dropping temp tables in SQL but it all comes from this experience.

I wonder if this has some connection to a limitation with SQLExpress. I do not know for certain.