Question

I am a .Net web developer working with a legacy Oracle database. In the past I have worked with orm tools like nHibernate but all database communication here is required to be done via stored procedures. Our dba is asking us to pass a bunch of administrative info to every procedure we call including the username/domain/ip of the end user. This data is then used to call another stored procedure that logs usage info each time a procedure is called.

I am not that well versed in Oracle or Pl/Sql and I am trying to write my .Net code in a clean way that meets best practices whenever possible. It seems to me that this process of passing extra data through to every procedure is messy and tedious on both the .Net and Oracle ends.

Does anyone know of a better way to accomplish the dba’s goal without all the overhead? Or is this a standard way of doing things that I should get used to.

Answer 1

I’d use a context rather than passing additional parameters to every stored procedure call. A context is a convenient place to store arbitrary session-level state data that the stored procedures can all reference.

For example, I can create a context MYAPP_CTX for my application and create a simple package that lets me set whatever values I want in the context.

SQL> create context myapp_ctx using ctx_pkg;

Context created.

SQL> create package ctx_pkg
  2  as
  3    procedure set_value( p_key in varchar2, p_value in varchar2 );
  4  end;
  5  /

Package created.

SQL> create package body ctx_pkg
  2  as
  3    procedure set_value( p_key in varchar2, p_value in varchar2 )
  4    as
  5    begin
  6      dbms_session.set_context( 'MYAPP_CTX', p_key, p_value );
  7    end;
  8  end;
  9  /

Package body created.

When the application gets a connection from the connection pool, it would simply set all the context information once.

SQL> begin
  2    ctx_pkg.set_value( 'USERNAME', 'JCAVE' );
  3    ctx_pkg.set_value( 'IP_ADDRESS', '192.168.17.34' );
  4  end;
  5  /

PL/SQL procedure successfully completed.

Subsequent calls and queries in the same session can then just ask for whatever values are stored in the context.

SQL> select sys_context( 'MYAPP_CTX', 'USERNAME' )
  2    from dual;

SYS_CONTEXT('MYAPP_CTX','USERNAME')
--------------------------------------------------------------------------------
JCAVE

Realistically, you’d almost certainly want to add a clear_context procedure to the package that called dbms_session.clear_context( 'MYAPP_CTX' ) to clear whatever values had been set in the context when a connection was returned to the connection pool to avoid inadvertently allowing context information from one session to bleed over into another. You would probably also design the package with separate procedures to set and to get at least the common keys (username, ip address, etc.) rather than having ‘USERNAME’ hard-coded multiple places. I used a single generic set_value method just for simplicity.