Benefits of context in Oracle 11g

Question

I spent a lot of time doing R&D on benefits of context but was somehow was not able to really understand the benefit of context in Oracle 11g. I would try to explain with an example, I have seen an example of database session-based application context where an ‘after logon database’ was using a context to raise_application_error if the user logged in was not in the employees table. I was wondering that the same thing can be implemented without the context to raise_application_error if the user logged in was not authorized.
I hope I have been able to explain my question properly about the exact benefits of contexts,
Please revert with the reply to my query.
Regards

Answer 1

I have seen an example of database session-based application context where an ‘after logon database’ was using a context to raise_application_error if the user logged in was not in the employees table.
Great! Post a link to what you 'saw' so we can see it to and get the FULL CONTEXT of what it ws doing and how it was doing it.
I was wondering that the same thing can be implemented without the context to raise_application_error if the user logged in was not authorized.
We have no way of knowing until we know WHAT the code you 'have seen' was doing and HOW it was doing it.
Maybe the same thing can be done without using contexts. But most examples are just that: examples. They try to show you the MINIMUM that must be done to illustrate what the functionality can do.
They often do NOT illustrate or discuss in detail WHEN to use contexts or WHAT problems contexts are most suited for.
First - we need to know WHAT contexts are. For that the Oracle docs can be used:
http://docs.oracle.com/cd/B28359_01/network.111/b28531/app_context.htm
What Is an Application Context?
An application context is a set of name-value pairs that Oracle Database stores in memory. The application context has a label called a namespace, for example, empno_ctx for an application context that retrieves employee IDs. Inside the context are the name-value pairs (an associative array): the name points to a location in memory that holds the value. An application can use the application context to access session information about a user, such as the user ID or other user-specific information, or a client ID, and then securely pass this data to the database. You can then use this information to either permit or prevent the user from accessing data through the application. You can use application contexts to authenticate both database and nondatabase users.
Note that the ONLY possible uses mentioned are authentication related - so more info is needed that just that intro.
Think of an application context as a global variable that holds information that is accessed during a database session
More info - global variables - available ANYTIME during a session. Note in particular it says NOTHING about any packages/functions/procedures being needed. Hmm - maybe we can use those 'global variables' in SQL queries?
But you ask about benefits - the doc has a section for that:
Benefits of Using Application Contexts
Most applications contain the kind of information that can be used for application contexts. For example, in an order entry application that uses a table containing the columns ORDER_NUMBER and CUSTOMER_NUMBER, you can use the values in these columns as security attributes to restrict access by a customer to his or her own orders, based on the ID of that customer.
Application contexts are useful for the following purposes:
  Enforcing fine-grained access control, for example, in Oracle Virtual Private Database polices
  Preserving user identity across multitier environments
  Enforcing stronger security for your applications, because the application context is controlled by a trusted procedure, not the user
  Increasing performance by serving as a secure data cache for attributes needed by an application for fine-grained auditing or for use in PL/SQL conditional statements or loops
This cache saves the repeated overhead of querying the database each time these attributes are needed. Because the application context stores session data in cache rather than forcing your applications to retrieve this data repeatedly from a table, it greatly improves the performance of your applications.
  Serving as a holding area for name-value pairs that an application can define, modify, and access
There are some benefits like you ask about
  Global application contexts.This type retrieves data that is stored in the System Global Area (SGA) so that it can be used for applications that use a sessionless model, such as middle-tier applications in a three-tiered architecture. A global application context is useful if the session context must be shared across sessions, for example, through connection pool implementations.
"Using Global Application Contexts" describes this type.
Interesting! This means you can truly have GLOBAL variables that are accesible by ALL USERS ACROSS SESSIONS.
How would you do that using other functionality?
The doc goes on to give other examples of 'benefits:
This section contains:
  About the Package That Manages the Database Session-Based Application Context
  Using SYS_CONTEXT to Retrieve Session Information
  Using Dynamic SQL with SYS_CONTEXT
  Using SYS_CONTEXT in a Parallel Query
  Using SYS_CONTEXT with Database Links
  Using DBMS_SESSION.SET_CONTEXT to Set Session Information
What about that SYS_CONTEXT function? That is in the Sql Language Doc
http://docs.oracle.com/cd/E11882_01/server.112/e41084/functions184.htm
Purpose
SYS_CONTEXT returns the value of parameter associated with the context namespace at the current instant. You can use this function in both SQL and PL/SQL statements. SYS_CONTEXT must be executed locally.
For namespace and parameter, you can specify either a string or an expression that resolves to a string designating a namespace or an attribute. If you specify literal arguments for namespace and parameter, and you are using SYS_CONTEXT explicitly in a SQL statement—rather than in a PL/SQL function that in turn is in mentioned in a SQL statement—then Oracle Database evaluates SYS_CONTEXT only once per SQL statement execution for each call site that invokes the SYS_CONTEXT function.
More benefits - contexts and the function can be used in 'both SQL and PL/SQL statements'. And because a SQL statement in PL/SQL that uses SYS_CONTEXT can be parsed at compile time that means that contexts are essentially treated as BIND variables and can dramatically improve performance in PL/SQL code of both standard SQL statements and DYNAMIC sql statements.