Contolling PL/SQL cartridge session

From: Andrei Filimonov <andrei.filimonov_at_supersolution.com>
Date: Wed, 01 Sep 1999 11:37:31 -0500
Message-ID: <37CD564B.2ED17F33_at_supersolution.com>



Hi, All!

There was a discussion on that subject some time ago but I still have a few questions remaining. The main issue was to be able to maintain a state of PLSQL packages being called from the PLSQL cartridge during the client session. That means that all package variables, cursors, records, collections, etc keep their values of states. In OAS 4.0.7 each request to PLSQL cartridge seems to reset PLSQL packages in the database. People from the Oracle OAS development team told me that enabling client sessions in the PLSQL cartridge ensures that each request that belongs to the session is handled by the same cartridge instance. But it doesn't guarantee that it uses the same database session hence the state of database PLSQL packages. They promised that in version 4.0.8 each cartridge instance will maintain the same database session.

We've got beta version of 4.0.8 a couple weeks ago and it seems to be working as promised. Now database PLSQL packages keep their state between requests. But one thing is still confusing. I was trying to keep track of database sessions created by PLSQL cartridge instance using either dbms_session.unique_session_id or userenv('SESSIONID') SQL function. To my surprise in both 4.0.7 and 4.0.8 the database session id returned was the same during client session. That means that PLSQL cartridge instance use the same database connection. Then how come that in version 4.0.7 all database packages get initialized at each request and do not in version 4.0.8? Am I missing something? Is there any way to "reset" database session without closing connection and keeping the same session id?

Another issue is if it's possible to control PLSQL session programmatically? In other words is there any way to force cartridge to abort client session and close database connection?

Andrei Filimonov Received on Wed Sep 01 1999 - 18:37:31 CEST

Original text of this message