When using encryption in SQL Server with symmetric keys, one needs to open the keys, and then one's supposed to close them afterwards. This would seem to create massive concurrency issues, because if a web application using a pooled connection is constantly opening and closing keys, it seems that the potential is high that one would get an error that one can't open the key because it's already open (because, say, another web user is calling a stored procedure that has already opened that key). And if one somehow allows the code to go through anyway with try/catch logic, that's even worse, because then one stored procedure could close a key before another one has finished using it.
It seems that this must be an issue many people have encountered, so I don't want to reinvent the wheel here. What are the best practices for avoiding concurrency problems in SQL Server when opening and closing keys? Do I simply need to have each stored procedure manage concurrency separately (say by calling sp_getapplock in every procedure that's going to use keys), or is there some cleaner solution for use with keys that's more centralized/manageable? (I searched for articles on encryption keys and concurrency issues but didn't find anything.)