>> This may destroy the ability to use connection pooling. Then each user will have there
>> own connections, increasing resources on the both the db server and web (or app) server.
>> Scalability and performance of your site will likely decrease. Or, if connection pooling still
>> works when using context_info, then you will run the risk of having the Context_info reset
>> on the connection, or being used by the wrong user. In an ASP app, there is no guarantee
>> that you will get the same connection each time. And, other users will share the same
Serving the Multilingual data with concept of ContextInfo technique does not destroy the ability of Connection Poolling. The extra overhead which comes is that every command has to precede with a Set ContextInfo call based on the User's context.
The connection Reset will not hamper the logic as the next call to the DB will precede again with a SetContextInfo call and hence different Users can share the same connection.
Of course, I don't think the author's intention was to claim that Context_Info was the solution to all of our security concerns. I think he merely chose that as an example of how to use it.
I wonder if you can change Context_Info repeatedly within a stored. Perhaps you could use it to output debugging info or something like that. Don't you hate when you have debugging statements in a procedure, but they don't get output until the procedure completes or fails? Maybe this can be used to output some debugging info as it runs. I don't know, just a thought.