Database Reference
In-Depth Information
These queries will display audit trail entries generated by proxy sessions. The first query displays all
proxy sessions—they have a PROXY_SESSIONID.
SELECT * FROM DBA_AUDIT_TRAIL WHERE PROXY_SESSIONID IS NOT NULL;
This next query finds the specific proxy connection associated with the session and shows the proxy
user for the connection. The results might appear as shown in Table 8-1. Our query actually returns
more columns than those shown in the Table.
SELECT p.username proxy, u.os_username, u.username, u.userhost, u.terminal,
u.timestamp, u.owner, u.obj_name, u.action_name, u.client_id, u.proxy_sessionid
FROM sys.dba_audit_trail u, sys.dba_audit_trail p
WHERE u.proxy_sessionid = p.sessionid
ORDER BY u.timestamp DESC;
Table 8-1. Example Audit Log Entries for Proxy Session
PROXY
OS_USERNAME
USERNAME
ACTION_NAME
CLIENT_ID
PROXY_SESSIONID
APPUSR
OSUSER
OSUSER
LOGOFF
OSUSER
68325
APPUSR
OSUSER
OSUSER
LOGON
68325
Using Connection Pools
If you are strictly concerned with desktop client applications, then you can skip this section. Connection
pools are generally only needed for multi-threaded, multi-user Server applications. A connection pool is
a collection of connections that are available for use by clients or client threads. As needed, a client will
acquire a connection from the pool, use it to query or update the Oracle database, and then return it to
the pool.
A connection pool usually exists for the duration of the JVM. Consider this scenario: a web
application server (for example, Tomcat) starts running and an application requests a connection from a
pool. At that point, a pool of connections is established, and one of the connections is provided to the
application. That specific application thread (typically tied to a user request—a browser seeking a
dynamic web page) will return the connection to the pool when the thread is done with it. Our
connection pool exists for use by all the web application threads (users browsing dynamic web pages)
until the web application server (Tomcat) is shut down.
We are going to spend sufficient effort here to demonstrate that our single sign-on will work from
any of the available connection pooling approaches. If you are using a Java Enterprise Edition (J2EE)
container (like a web application server) and you use Enterprise Java Beans (EJBs), then chances are
good that you are using connection pooling by way of a “container-managed connection pool.”
Proxy Connections from an OCI Connection Pool
An Oracle call interface (OCI) connection pool is a traditional approach to connection pools, and our
approach to single sign-on can succeed within it. OCI is a technology that supersedes Java and is not a
“pure java” implementation. We would say that using ojdbc, Java is able to call OCI as an external
resource.
 
Search WWH ::




Custom Search