Skip to Main Content


Question and Answer

Connor McDonald

Thanks for the question, Vinayak.

Asked: October 15, 2006 - 11:39 am UTC

Last updated: June 13, 2022 - 8:44 am UTC

Version: 9.2.0

Viewed 10K+ times! This question is

You Asked

Hi Tom,
Please clarify the following points:
1.what is the difference between local context and global context?
2.For a session, can both exists and if yes, what differentiates them?
3.I have heard that this concept is basically used for web based application because of the concept of connection pooling used by them.But why can't we have only one context. i.e whats the need of two context. In what condition/scenario can these be different?
4.Pointers to any online Oracle docs regarding this?


and Tom said...

1) there are application contexts - private to a particular session and expire (disappear) when the session goes away.

Then there are global application contexts - contexts that may be shared across sessions (like a global variable) and survive session creation and deletion (only a database "bounce" truly gets rid of them)

2) yes, the CREATE statement differentiates them. And - to get a global application context - you have to "attach" it to your session - it is not "just there", you need the sessionid and might have to be logged in using a specific userid as well.

3) one is specific to a session, works well in a STATELESS environment. the other works over sessions - good for a STATEFULL environment (where you need to maintain the state from call to call). You might use a global application context for example if your "authentication" process is "expensive" (eg: to authenticate a client web browser, you need to make a series of LDAP call outs). instead of re-retreiving that data every time that web session (which is not a database session) makes a call, you might plop those values into a global application context - and then just attach that context to the database session as you grab connections from the connection pool.

4) application developers guide, sql reference manual - definitely.

</code> <code>


  (10 ratings)

Is this answer out of date? If it is, please let us know via a Comment


Alberto Dell'Era, October 15, 2006 - 2:01 pm UTC

Does global and "local" application contexts' state reside in memory - or in some system table ?


Tom Kyte
October 16, 2006 - 7:35 am UTC

they are memory things, pga or sga

Where context values reside

Andrew Max, October 15, 2006 - 2:22 pm UTC

Hi Alberto

I'm not even trying to predict Tom's answer - just my thoughts.

Local and global context values can be seen via V$CONTEXT and V$GLOBALCONTEXT fixed views, respectively. And if we query V$FIXED_VIEW_DEFINITION, we'll see that they are subsets of fixed tables X$CONTEXT and X$GLOBALCONTEXT.

As far as I know, X$-tables are not "true" tables – they are nothing but internal memory structures used by Oracle. So we can assume that context values are stored in memory, not in physical tables.

Maybe I'm wrong so let's wait for Tom's reply.


Tom Kyte
October 16, 2006 - 7:36 am UTC

nope, you got it.

A little more clarification !!!

Vinayak, October 16, 2006 - 4:26 am UTC

As usual , your explanation was very helpful. I couldn't understand point 2 that "CREATE" differentiates them. Which CREATE statement you are talking about? Could you please explain this.

Tom Kyte
October 16, 2006 - 7:52 am UTC

you asked what "differentiates" them - their creates do:

ops$tkyte%ORA10GR2> create or replace context my_app_ctx using p;

Context created.

ops$tkyte%ORA10GR2> create or replace context my_GLOBAL_app_ctx using p accessed globally;

Context created.


to Vinayak

Michel Cadot, October 16, 2006 - 7:49 am UTC

Global context are created with the clause "ACCESSED GLOBALLY".


Thanks again....

Vinayak, October 16, 2006 - 8:05 am UTC

Thanks for the example. That was very helpful.

where global context resides?

yoni, August 14, 2011 - 1:22 pm UTC

The local context resides in the PGA,
the global context resides in the SGA but where (in the shared_pool/buffer_cache/..)?
as far as i know the global_context_pool_size param is deprecated (from 10.1).

So how can i determined the global context size in the memory? and how can i know its current size in the SGA?


where to see global context usage

Paul, November 01, 2012 - 6:00 am UTC

you can see the current global context usage by
select * from v$sgastat where name='Global Context';
You'll see that it resides in shared_pool

Performance of global context

kanagaraj, July 02, 2014 - 8:38 pm UTC

Can I use the global context as a cache to store application specific configuration options?. Is there any performance issues in using the global context over global package variables?

Memory issues with global context

Scott Wesley, June 13, 2022 - 8:21 am UTC

If I may address the following:
only a database "bounce" truly gets rid of them

If we add x number of global contexts with each logon/session created, the memory usage thus grows. Eventually, this will reach capacity.

Even with a call to
to clear any contexts whose session is no longer active - this doesn't relieve the memory issue (bug 9387214), and requires a (11g) database bounce?

How is using global context a scalable option?

Connor McDonald
June 13, 2022 - 8:44 am UTC

Can you clarify - you talking about a *single* global contex with lots of client_ids? or lots of contexts?

And for "Even with a call to sys.dbms_session.clear_context to clear any contexts whose session is no longer active" is this:

- a session that still exists by is idle?, or
- a session that is gone (disconnected)


Scott Wesley, June 15, 2022 - 12:03 am UTC

I'm talking about a single namespace with one client ID for each session that a user creates - be it Forms or APEX.
  sys.dbms_session.set_context (
     namespace => gc_namespace -- one namespace
    ,attribute => 'ATTRIBUTE_X' -- handful of these per session
    ,value     => pc_value_x
    ,client_id => dbf_get_client_id -- format user:session_id

As per the following methodology, with Forms users retrofitted to the same client ID format.

Our batch process attempts to clean up contexts for sessions no longer in user.
For Forms users, this means the session ID is no longer present in v$session.
For APEX users, this means the sysdate is greater than the relevant session life timeout in apex_workspace_sessions, or if the session ID no longer exists there.