>> 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
>> connection.
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.
