The 12.0.1 Help on Plan caching says "The plan cache is a per-connection cache of the data structures used to execute an access plan."
However, observed behavior would indicate that "per-connection" may not apply when the separate connections are different invocations of the same web service... that a Very Bad Plan cached for a Query From Hell inside a web service stored procedure can persist (for a while, long enough to confuse(1) the observer :) across multiple invocations of the web service.
I suspect the details are complex and hard to explain for us Deltas (ok, Gammas :) but any attempt to do so would be welcome!
Footnote (1): An example of "confuse the observer" is "How come the new clustered index makes my plan look a million times faster in the ISQL Plan Viewer, but my web service is still running slow? ...no, wait, NOW it's faster, after running it fifty times!"
In a comment on his answer to a related question Mark Culp wrote this: "We have discussed (and have experimented with) cross connection plan caching but it is hard to get it right so this feature has not (yet) made it into the released product."
If I remember correctly in SA 12 we introduced connection pooling for web service requests. This means that the database connection is put back into a pool when the web service request completes. If a new web service request arrives for the database within a short period of time (30 seconds I think) then the database connection will be pulled out of the pool and used to handle the request. This pooling technique saves the time to create and tear down the database connection ... but the new web service request must still go through the same parsing, mapping, and authentication process.
Now here's the rub: to ensure that there is no leakage of information from one request to the next, when a connection goes into the pool the connection is "cleaned" by closing all cursors, dropping all temp tables and connection variables, and a few other things (that I can't remember right now).
Net result is that the plan cache is
I say "normal" web requests because if you are using HTTP sessions then everything that I have said above does not apply. When you use HTTP sessions the database connection used to handle the web request is maintained completely intact between web requests - the connection is associated with the HTTP session and will only be used to handle requests associated with the session and therefore there is no concern about information leakage between requests (since that is exactly why you would use sessions - to keep information on the connection between requests) and therefore the no cleaning is performed.
So how do you solve the "I have a bad cached plan; how do I get rid of it?"? You have two methods:
The first solution is likely easiest to do on a running system.