I haven't written many web services up to this point in my life, although I'm about to lead the development of a suite of services intended as an API for our solution. Because of this, the experience I've just had bothers me.
I knocked together a very simple web service for a client, with two methods, one to get some data and one to perform an update. They appeared to work fine, until they got down to some integration testing, at which point they started to throw intermittent exceptions.
A little bit of playing about from a Console app revealed that you could call the querying service as much as you liked, but as soon as you called the update service, the querying service stopped finding rows in the table. Obviously this is all remote and not on our servers, so debugging was basically impossible. I've spent the afternoon adding explicit transactions to the code, changing static declarations to instance, setting the TransactionOption property in the WebMethod attribute, all sorts. Finally my increasingly random searching threw up a 15 Seconds post about connection pooling, so I added "Pooling=False" to the connection string in the config file and that, annoyingly, fixed it.
I'm doubly annoyed now because I've made the problem go away without actually solving it: I don't know why or how pooling was causing the problem. There was no mention of transactions in the code to start with (it's a single update statement in a stored procedure), and when I added a transaction it was committed or rolled back immediately. All the SqlConnection, SqlCommand and SqlDataReader variables were neatly wrapped in using statements, so they should have been dead and gone by the time the service was recalled.
If anybody understands this better than me, please send your explanation on a postcard to "Confused, Tunbridge Wells".