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 ?
TIA
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.
Regards.
October 16, 2006 - 7:36 am UTC
nope, you got it.
A little more clarification !!!
Vinayak, October 16, 2006 - 4:26 am UTC
Tom,
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;
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
CREATE CONTEXT statement.
Global context are created with the clause "ACCESSED GLOBALLY".
Regards
Michel
Thanks again....
Vinayak, October 16, 2006 - 8:05 am UTC
Tom,
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?
thanks.
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 themIf 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
sys.dbms_session.clear_context
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)
Clarification
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.
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.
July 05, 2022 - 1:15 am UTC
And can you tell me how you are calling clear_context - how many args you passing ?
Clear context usage
Scott Wesley, July 06, 2022 - 3:57 am UTC
Currently sending all three parameters - not sending null for attribute.
These values are being fed from v$globalcontext, for sessions we deem no longer in use.
ie - not in v$session or apex_workspace_sessions
sys.DBMS_SESSION.clear_context(
namespace => gc_namespace
,client_id => pc_client_id
,attribute => pc_attribute
);
July 07, 2022 - 4:30 am UTC
Internally we have 2 structures (think of them as parent/child).
Parent: One row for each: context name, client_id
Child: One row for each: context name, client_id, attribute
Calling "clear_context" with three params will clear out the child 'table' but never touch the parent 'table'. Thus the parent exists until database bounce.
But calling 'clear_context' with TWO params (no attribute) should clear both child and parent structures.
Confirmation
Scott Wesley, August 02, 2022 - 6:30 am UTC
Thanks, Connor.
Our verification script shows memory is reclaimed when the attribute parameter is not supplied.
August 04, 2022 - 11:53 am UTC
Glad we could help