Introducing Application Context - from the PL/SQL Potpourri

Application Context

Lucas Jellema, KC Server Development – PL/SQL Potpourri, 20th Januariy2009

Application Context

Lucas Jellema

AMIS

KC Server Development

PL/SQL Potpourri

20th January 2009

Application Context


Overview

Application Context provides part of the environment

in which a session is executing statements

Part is system defined – context USERENV

Part is developer controlled – CLIENTCONTEXT and user

defined contexts

The Application Context is the link for context meta-

data between applications and the database

Applications should set the proper context values before

executing SQL and PL/SQL statements

Application Context is sometimes a more elegant and

better performing alternative to global package variables

And an essential part of VPD – Virtual Private Database

Application Context


Introducing Application Context

An Application Context is

Named area

With key-value pairs

• Key and Value are both

string values

(Usually) part of the

session scope

• Just like global package

variables

Values can only be added through a PL/SQL package

Values can be read in SQL queries and PL/SQL code

Through the SYS_CONTEXT operator

Name Value

OrgId 14

Locale fr_ca

Timezone +2.00

WebClient_CtxCurrency_Ctx

View_Ctx

Application Context


Application Context

Enables application developers to define, set, and access

application attributes by serving as a data cache

This removes the repeated overhead of querying the

database each time access to application

attributes is needed

Two Application

Contexts are always

around:

CLIENTCONTEXT

USERENV

Attribute Value

Attribute Value

Namespace

Attribute Value

Pairs

Application Context


Application Context

Values can be read from an Application Context using SYS_CONTEXT, both in SQL as well as PL/SQL

Pass in the name of the Application Context and the name of the Attribute you are looking for

If you ask for an Application Context that does not exist, NULL is returned

If you ask for an attribute that does not exist, ORA-2003 – invalid <app context> parameter is raised

select sys_context('USERENV', 'SESSION_USER')

from dual

l_user:= sys_context('USERENV', 'SESSION_USER')

Application Context


USERENV

ACTION

AUDITED_CURSORID

AUTHENTICATED_IDENTITY

AUTHENTICATION_DATA

AUTHENTICATION_METHOD

BG_JOB_ID

CLIENT_IDENTIFIER

CLIENT_INFO

CURRENT_BIND

CURRENT_SCHEMA

CURRENT_SCHEMAID

CURRENT_SQL

CURRENT_SQL_LENGTH

DB_DOMAIN

DB_NAME

DB_UNIQUE_NAME

ENTRYID

ENTERPRISE_IDENTITY

FG_JOB_ID

GLOBAL_CONTEXT_MEMORY

GLOBAL_UID

HOST

IDENTIFICATION_TYPE

INSTANCE

INSTANCE_NAME

IP_ADDRESS

ISDBA

LANG

LANGUAGE

MODULE

NETWORK_PROTOCOL

NLS_CALENDAR

NLS_CURRENCY

NLS_DATE_FORMAT

NLS_DATE_LANGUAGE

NLS_SORT

NLS_TERRITORY

OS_USER

POLICY_INVOKER

PROXY_ENTERPRISE_IDENTITY

PROXY_GLOBAL_UID

PROXY_USER

PROXY_USERID

SERVER_HOST

SERVICE_NAME

SESSION_USER

SESSION_USERID

SESSIONID

SID

STATEMENTID

TERMINAL

Application Context


Storing values in standard context CLIENTCONTEXT

Values can be set in the Application Context CLIENTCONTEXT

CLIENTCONTEXT needs not be set up, it is always there

It is session bound – not accessible in other sessions, stored in UGA

The value can be read – in the same session – using:

begin

dbms_session.set_context

( 'CLIENTCONTEXT' -- Namespace

, 'dollar_to_euro_ratio' -- Attribute

, '0.67' -- Value

);

end;

Application Context


Creating an application specific context

Application Context is a named container with a set of key-value pairs. A per session instance is stored in UGA

An Application Context is associated with a package Only through the package can values be set in the context

Setting values is not tied to the transaction (no commit dependency)

Values in the context can be used in where conditions These are treated as bind-parameters!

deptno = sys_context('Hrm_Ctx', 'dept')

create context Hrm_Ctx using HrmPkg

deptno = :b1

Application Context


Distinction with global package variables

Values from Application Context are treated as bind variables There value is established before the query is executed

While functionally similar, the execution for these two queries is quite different:

and

select *

from big_table

where country_column = package.get_current_country

select *

from big_table

where country_column =

sys_context('App_Ctx', 'current_country')

Application Context


Create the HRM_CTX Context

create or replace context hrm_ctx using hrm_pkg

create or replace package body hrm_pkg

is

procedure set_language (p_language in varchar2)

is

begin


('HRM_CTX' , 'LANGUAGE' ,p_language);

end set_language;

procedure clear_context is

begin

dbms_session.clear_context('HRM_CTX');

end;

...select *

from session_context

Application Context


Create the HRM_CTX Context

Application Context


Use cases for Application Context

Programmable/Configurable View

Meta Data Interface between Application and Database

Client User Identity – and other environment settings

• Get rid of hard coded references to USER!

Instrumentation

Setting default values

Cache for ‘expensive’ and/or ‘shared’ values

Foundation for VPD

Application Context


Configurable View

Generic challenge: create a view that has run-time

parameters governing its behavior

For example:

View EMP_REPORT_VW

Returns the Average Salary and Number of Employees

• Per Job and Department and Year of hiring

• or: Over all Employees

• or: Per Job

• or: Per Department and Year of Hiring

• or: any other combination

It depends on the caller which should be the case!

• The caller should provide ‘input parameters’ to get the desired

behavior from this view

Application Context


Configurable View EMP_REPORT_VW

Application Context


Approach this challenge

Clearly this view uses data from meta data environment

That indicates which column(s) to group by

The view accesses this data from an Application

Context using SYS_CONTEXT

Setting the data is done through a simple call to a

package, preceding the query against the view

Note: for client technologies that have a problem calling

PL/SQL packages, we could create a View called

EMP_REPORT_VW_PARAMETERS with an INSTEAD OF

trigger that will convert an update of a parameter to a call to

the package that controls the Application Context.

Application Context


Implementing Configurable View

Application Context


Implementing Configurable View (2)

If group by department, then show deptno

If group by department, then group by deptno

else group by null (which has no effect)

Application Context


Calling the configurable view

Application Context


The client is always right

What time is it

or at least what is the client’s timezone

What locale is it

which language/regional settings apply

Where is it located

what is the geographical location

Who is it

web user’s identity <> any database user

Note: The database can only serve!

Following the client’s lead

Application Context


USER <> CLIENT_IDENTIFIER

Many – and ever more –

applications make use of

light-weight users

That do not correspond

to database users

These applications will

inform the database

through setting the Client

Identifier about the user

Referring to USER is (ever

more) meaningless!

J(2)EE Application Server

Web Application

Client

LDAP

APPLICATION_SCHEMA

USERENV

Application Context


Set Client Identifier with Light Weight User

In Java using Oracle JDBC Driver

In PL/SQL

Or use a logon trigger to derive the client identifier

conn.setClientIdentifier("john.doe")

DBMS_SESSION.SET_IDENTIFIER( 'john.doe');

CREATE OR REPLACE TRIGGER logon_trigger

AFTER LOGON ON DATABASE

DECLARE

uid VARCHAR2(64);

BEGIN

SELECT ora_login_user ||':'

||SYS_CONTEXT('USERENV', 'OS_USER')

INTO uid

FROM dual;

dbms_session.set_identifier(uid);

END logon_trigger;

Application Context


Set Client Identifier with Light Weight User

In the database – SQL or PL/SQL – the current client identifier can be read like this:

The Client Identifier is also available in V$SESSION

as well as V$SQLAREA

DBMS_MONITOR.CLIENT_ID_TRACE_ENABLE allows for tracing all activity of a CLIENT_IDENTIIER aka light-weight user

Note: Oracle standard auditing does not use

CLIENT_IDENTIFIER

SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')

SELECT sid, client_identifier, service_name

FROM v_$session;

Application Context


A properly instrumented application...

Should tell the database

Who is the actual user for whom it is running

Which Module requests database actions & for what purpose

(optionally) Additional information about the client

begin

dbms_application_info.set_module

( module_name => 'MODULE_NAME'

, action_name => 'What is the module doing'

); -- sets columns Module&Action in V$SESSION view

dbms_application_info.set_client_info

( client_info => 'extra info e.g. Task Context'

); -- no longer than 64 chars, sets column Client

-- Info in the V$SESSION view

dbms_session.set_identifier('id for real user');

-- sets v$session view column CLIENT_IDENTIFIER

end;

Application Context


Guideline: provide application with Instrumentation API

Define an API (PL/SQL procedure) that applications can

call to provide all instrumentation information

This API will take care of

setting the proper values

in Application Context

and through

dbms_application_info

Requires but a single call

J(2)EE Application Server

INSTRUMENTATION_API

Web Application

dbms_application_

info

dbms_session

Application Context


Retrieving the ‘instrumented values’

select sys_context('USERENV','sid') sid, sys_context('USERENV','module') module, sys_context('USERENV','action') action, sys_context('USERENV','client_identifier')

client_identifier, sys_context('USERENV','client_info') client_infofrom dual/

select sid, module, client_identifier, client_info, actionfrom v$session/

Application Context


Default values for audit columns

The default value of a column can be specified using a

reference to an application context:

That can be a reference to a user defined context too:

Note: you can refer to default in UPDATE statement

CREATE TABLE IMPORTANT_RECORDS( ...

, USER_CREATED VARCHAR2(100) DEFAULT

SYS_CONTEXT('USERENV','CLIENT_IDENTIFIER')

CREATE TABLE IMPORTANT_RECORDS( ...

, PRICE VARCHAR2(100) DEFAULT

SYS_CONTEXT('ORDER_APP','CURRENT_PRICE')

UPDATE IMPORTANT_RECORDSSET PRICE = DEFAULTWHERE ...

Application Context


Create Context as Globally Accessible

Accessible throughout the entire instance:

Every session can retrieve values

Stored in SGA (instead of UGA)

• A big difference compared to package variables!!

For global settings, cross application parameters

• For example once-per-day calculated or retrieved (from web

services?) values that remain available throughout the day

Application Context


Globally Accessible

Application Context


Globally Accessible: Accessing Values

Application Context


Application Context values associated with Client Identifier

Application Context can be private (tied to a session) or

globally accessible (across all sessions)

Third option: attributes associated with Client Identifier:

only sessions with the same Client Identifier can access an

those attributes of such a context


( namespace=> 'HRM_CTX'

, attribute => 'my_org_id'

, value=> '67'

, client_id =>

sys_context('USERENV','CLIENT_IDENTIFIER')

);

Application Context


Application Context associated with Client Identifier

Retrieving session specific values is handled by the

database automatically, using the CLIENT_IDENTIFIER

If HRM_CTX has a value associated with the client identifier,

it is returned; otherwise the non associated value is returned

To remove all values tied to a specific client_identifier

from an application context:

SYS_CONTEXT('HRM_CTX', 'my_ord_id')

... –- still package hrm_pkg managing HRM_CTXprocedure clear_context isbegindbms_session.clear_context('HRM_CTX', sys_context('USERENV','CLIENT_IDENTIFIER') );

end;

Application Context


Summary

An Application Context is a named in-memory set of key-value pairs

Application Context value references in SQL queries are processed like bind parameters

A Context is by default associated with a single session

Alternatively a context can be global (cross session) or

associated with a Client Identifier

Application Context is used for

Exposing System and Session attributes (USERENV)

Configurable Views

Application to Database meta data interface

Global cross-session shared in memory cache

Virtual Private Database

Technology

Introducing Application Context - from the PL/SQL Potpourri