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 ?
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
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.
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.
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;
ops$tkyte%ORA10GR2> create or replace context my_GLOBAL_app_ctx using p accessed globally;
Michel Cadot, October 16, 2006 - 7:49 am UTC
CREATE CONTEXT statement.
Global context are created with the clause "ACCESSED GLOBALLY".
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?
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.
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. https://jeffkemponoracle.com/2013/02/apex-and-application-contexts/
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.