Which two statements are true about the context of an application? (Choose two.)
A.
It is attached to a session.
B.
It is owned by the user SYS.
C.
A user can change the context of his or her application.
D.
The PL/SQL package associated with the context must exist before the context is created.
E.
The predefined attributes in the USERENV application context can be changed as per the
requirements.
http://docs.oracle.com/database/121/DBSEG/app_context.htm#DBSEG165
http://docs.oracle.com/database/121/DBSEG/app_context.htm#DBSEG70005
It seems that A is incorrect:
“A global application context enables application context values to be accessible across database sessions, including Oracle RAC instances. Oracle Database stores the global application context information in the System (sometimes called “Shared”) 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.”
B is probably correct. The following is true for Database Session-Based Application Contexts and Global Application Contexts: “The ownership of the application context is as follows: Even though a user who has been granted the CREATE ANY CONTEXT and DROP ANY CONTEXT privileges can create and drop the application context, it is owned by the SYS schema”. But I’m not sure about Client Session-Based Application Contexts.
“You can assign the values to the application context attributes at run time, not when you create the application context. Because the trusted procedure, and not the user, assigns the values, it is a called secure application context.” So I’m not sure about C.
According to the tutorials D is incorrect too.
“Remember that you only use USERENV to retrieve session data, not set it.” So E is also wrong.
A)
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.
B)
The ownership of the application context is as follows: Even though a user who has been granted the CREATE ANY CONTEXT and DROP ANY CONTEXT privileges can create and drop the application context, it is owned by the SYS schema. Oracle Database associates the context with the schema account that created it, but if you drop this user, the context still exists in the SYS schema. As user SYS, you can drop the application context.
C:
http://docs.oracle.com/cd/B28359_01/network.111/b28531/vpd.htm#DBSEG98219
You can use application contexts with Oracle Virtual Private Database policies. When you create an application context, it securely caches user information. Only the designated application package can set the cached environment. It cannot be changed by the user or outside the package. In addition, because the data is cached, performance is increased. Chapter 6, “Using Application Contexts to Retrieve User Information” describes application contexts in detail.
B , C
OPS, I DIDN’T REMEMBER
DBMS_SESSION.SET_CONTEXT… SO IT’S ATTACCHED TO A SESSION… A , B
A, B
A.
Components of the Application Context
An application context has two components, comprising a name-value pair.
Think of an application context as a global variable that holds information that is accessed during a database session.
Types of Application Contexts
– Database session-based application contexts.
This type retrieves data that is stored in the database user session (that is, the UGA) cache.
– Global application contexts.
A global application context is useful if the session context must be shared across sessions,
for example, through connection pool implementations.
– Client session-based application contexts. This type uses Oracle Call Interface functions on the client side
to set the user session data, and then to perform the necessary security checks to restrict user access.
B.
About Creating Database Session-Based Application Contexts
The ownership of the application context is as follows: Even though a user who has been granted the CREATE ANY CONTEXT and DROP ANY CONTEXT privileges can create and drop the application context, it is owned by the SYS schema.
http://docs.oracle.com/database/121/DBSEG/app_context.htm#DBSEG165