Shared Session Data

Question

Hello Everyone,
I have a problem that I could not seem to find a solution or best methods and practices for.
I have session level data abstracted by a package API and accessed query-inline via a table function. All this works fine; however, there is one caveat that does not. The query SQL is passed to a jobs table and executed by a scheduled job. So the job session can not see the user session data.
Is there a way to:
1) Share Session data?
2) define a table as containing Session temporary data, but public scope?
3) Group Sessions or grant session privileges (to share scope)?
4) Run a process/job under a different Session ID, or with specific Session privileges?
5) Call a procedure or function from one session, but have it Execute under a different session?
As it stands, I can either copy the data out to a permanent table (and manually implement Session ID, and Session level cleanup), change the current API and underlying global temporary table to a permanent table (and again manually implement Session ID, and Session level cleanup), or before job scheduling parse the SQL, and expand the function table data into the SQL statically.
None of these are solutions I like. I am looking for something more elegant. Any suggestions would be appreciated.
*EDIT: sorry, I forgot to add; I'm using Oracle 10g.
Thank you for your time.
Edited by: user10921261 on Mar 20, 2009 11:57 AM

Answer 1

Aequitas wrote:
I have session level data abstracted by a package API and accessed query-inline via a table function. All this works fine; however, there is one caveat that does not. The query SQL is passed to a jobs table and executed by a scheduled job. So the job session can not see the user session data.Correct. As a job is a brand new session that is created to execute the supplied PL/SQL code. This process does not create the session by inheriting the environment (name space details, temp tables, transactions) of the session that submitted the job.
Imagine the complexities of this when the session that created the job, terminated 24 hours ago.... would it session state (if kept persistent) still apply? And what about the complexities dealing with the overheads to somehow and somewhere store this session data for the job to re-use.
Nope.. this is not a workable solution (and nor a sensible one), so Oracle does not support it. When a job is executed, a brand new session is created for that job. (not entirely correct at a technical level as the job queue process may already exist and already have a session - but conceptually, think of a brand new session for a job).
Is there a way to:
1) Share Session data?What session data specifically? And what about a session that long since ceased to exist? What about session data that is dynamic and changing? Should then job see the version of that data at the time it was submiited? At the time is started execution? Or the data as it is currently within that session?
2) define a table as containing Session temporary data, but public scope?Does not need to have a "public scope". It can be managed via an API (PL/SQL), using the job number as unique reference number. It is even possible to create low level access control on such a table that only the job and no-one else can even see the data in that table, except for the job.
3) Group Sessions or grant session privileges (to share scope)?Nope.
4) Run a process/job under a different Session ID, or with specific Session privileges?Which session privileges? Remember that each session has two basic memory areas - the PGA (Process Global Area) and UGA (User Global Area). Both are private and non-sharable.
5) Call a procedure or function from one session, but have it Execute under a different session?Nope.
As it stands, I can either copy the data out to a permanent table (and manually implement Session ID, and Session level cleanup), change the current API and underlying global temporary table to a permanent table (and again manually implement Session ID, and Session level cleanup), or before job scheduling parse the SQL, and expand the function table data into the SQL statically.Still not sure what you imply with session data.
In my case I have a process API (running on top of DBMS_JOB ) that developers use to schedule jobs (it manages external processes, mostly used for collecting data from other non-db servers). In some cases, the caller is a Virtual Private Database (VPDB) session - with a name space that contains the keys and tokens and what not that is required for access control and security. The name space cannot be copied across to the job.
So as part of the process API that creates the job, a logon/authentication/authorisation call is added. With the calling session username. This is the same call that would have been made when the user session was created at logon time. And this call creates the name space that contains the keys and tokens required. Thus creating that batch (job) session in the background, uses the same initialisation processing that an interactive session (created from the app server) would use. The code running in that job is oblivious to the fact that the session was not created via an interactive logon from the app server.
None of these are solutions I like. I am looking for something more elegant. Any suggestions would be appreciated.If you truly want an IPC mechanism between two sessions in Oracle, two methods come to mind. Database pipes. Advance Queuing.
This is not really that complex to implement. IPC itself is not difficult. The difficult part is designing the code around cross-session communication and have that work effectively and efficiently. And within the database session context, this can be not only quite difficult to do, but also not always the very sensible thing to do.