92 Configuring Exclusive Isolated Client Sessions for Virtual Private Database

This chapter describes the various components that you must configure before you can acquire an exclusive isolated client session from a server session.

This chapter includes the following sections:

Table 92-1 lists the configurable options for isolated sessions.

92.1 Introduction to Exclusive Isolated Client Session Configuration

Table 92-1 lists the configurable options for isolated sessions.

Table 92-1 Configurable Options for Isolated Client Sessions

Option to Configure Oracle JDeveloper
TopLink Workbench
Java

Cache isolation at the descriptor level (see Section 119.13, "Configuring Cache Isolation at the Descriptor Level")

Unsupported Unsupported Supported

Connection policy (see Section 89.12, "Configuring Connection Policy")

Unsupported Unsupported Supported

Oracle Database proxy authentication using Java (see Section 98.8.1, "How to Configure Oracle Database Proxy Authentication Using Java")

Unsupported Unsupported Supported

PostAcquiredExclusiveConnection event handler (see Section 92.2, "Using PostAcquireExclusiveConnection Event Handler")

Unsupported Unsupported Supported

PreReleaseExclusiveConnection event handler (see Section 92.3, "Using PreReleaseExclusiveConnection Event Handler")

Unsupported Unsupported Supported

NoRowsModifiedSessionEvent event handler (see Section 92.4, "Using NoRowsModifiedSessionEvent Event Handler")

Unsupported Unsupported Supported

ValidationException handler (see Section 92.5, "Accessing Indirection")

Unsupported Unsupported Supported

These options are used throughout the isolated session life cycle (see Section 87.5.1.3, "Isolated Client Session Life Cycle").

92.2 Using PostAcquireExclusiveConnection Event Handler

TopLink raises this event after an exclusive connection is allocated to an isolated session after the user has logged in to the database with it.

If you are using Oracle Database proxy authentication (see Section 96.1.4.2, "Oracle Database Proxy Authentication"), then you do not need to implement this session event handler.

If you are not using Oracle Database proxy authentication, then, as part of the isolated session life cycle, you must implement a SessionEventListener for SessionEvent.PostAcquireExclusiveConnection.

Note:

You must add this session event listener to the server session from which you acquire your isolated client session. You cannot add them to the isolated client session itself. For more information, see Section 89.10, "Configuring Session Event Listeners"

92.2.1 How to Use Java

The SessionEvent.PostAcquireExclusiveConnection event listener is your opportunity to authenticate your user and interact with the underlying database platform: for example, to execute PL/SQL to create VPD packages and set VPD context information.

Example 92-1 illustrates a typical session event listener used to handle postAcquireExclusiveConnection events for an isolated session.

Example 92-1 Session Event Listener for an Isolated Session

class VPDEventListener extends SessionEventAdaptor{
    public void postAcquireExclusiveConnection(SessionEvent event){
        ClientSession session = (ClientSession)event.getSession();
        // Get property set on the ConnectionPolicy prior to acquiring the connection
        String userLevel = session.getConnectionPolicy().getProperty("userLevel");
        // Make the Stored Procedure call for VPD to set up the Context Information
        session.executeNonSelectingSQL("StoreProcSetContextUser("+ userLevel + ")");
    }
}

To get the required user credentials, use ClientSession method getConnectionPolicy to get the associated ConnectionPolicy, and then use ConnectionPolicy method getProperty. The ConnectionPolicy associated with the ClientSession should contain all required user credentials (see Section 89.12, "Configuring Connection Policy").

After you implement the required SessionEventListener, add it to the parent server session from which you acquire your isolated client session. For more information, see Section 89.10, "Configuring Session Event Listeners".

92.3 Using PreReleaseExclusiveConnection Event Handler

TopLink raises a SessionEvent.PreReleaseExclusiveConnection event after you call the isolated session method release.

If you are using Oracle Database proxy authentication (see Section 96.1.4.2, "Oracle Database Proxy Authentication"), then you do not need to implement this session event handler.

If you are not using Oracle Database proxy authentication, then as part of the isolated session life cycle, you must implement a SessionEventListener for SessionEvent.PreReleaseExclusiveConnection.

Note:

You must add this session event listener to the server session from which you acquire your isolated client session. You cannot add them to the isolated client session itself. For more information, see Section 89.10, "Configuring Session Event Listeners"

92.3.1 How to Use Java

The SessionEvent.PreReleaseExclusiveConnection event listener gives you an opportunity to interact with the underlying database platform: for example, to perform any VPD-specific cleanup such as executing PL/SQL to delete VPD packages or context information.

Example 92-1 illustrates a typical session event listener used to handle preReleaseExclusiveConnection events for an isolated session.

Example 92-2 Session Event Listener for an Isolated Session

class VPDEventListener extends SessionEventAdaptor{
    public void preReleaseExclusiveConnection(SessionEvent event){
        Session session event.getSession();
        // Make the Stored Procedure call for VPD to reset the Context Information
        session.executeNonSelectingSQL("StoreProcResetContext()");
    }
}

To get the required user credentials, use ClientSession method getConnectionPolicy to get the associated ConnectionPolicy, and then use ConnectionPolicy method getProperty. The ConnectionPolicy associated with the ClientSession should contain all required user credentials (see Section 89.12, "Configuring Connection Policy").

After you implement the required SessionEventListener, add it to the parent server session, from which you acquire your isolated client session. For more information, see Section 89.10, "Configuring Session Event Listeners".

92.4 Using NoRowsModifiedSessionEvent Event Handler

As part of your general error handling strategy, you should implement a SessionEventListener for SessionEvent.NoRowsModifiedSessionEvent.

TopLink raises this event when an update or delete query is executed against the database, but no rows are updated, that is, a zero row count is returned.

If optimistic locking is not enabled and you query the database and violate your VPD security configuration, no exception is thrown: the query simply returns zero rows updated.

If optimistic locking is enabled and you query the database and violate your VPD security configuration, an OptimisticLockException is thrown even though the root cause of the failure was a security violation, not an optimistic locking issue.

Note:

You must add this session event listener to the server session from which you acquire your isolated client session. You cannot add them to the isolated client session itself. For more information, see Section 89.10, "Configuring Session Event Listeners"

92.4.1 How to Use Java

This event listener gives you an opportunity to determine whether the update failure was due to a security violation (in which case you should not retry the operation), or due to an optimistic lock issue (in which case a retry may be appropriate).

You can use the existing session event API, such as getQuery().getResult(), to get the affected object, if any.

After you implement the required SessionEventListener, add it to the parent server session, from which you acquire your isolated client session. For more information, see Section 89.10, "Configuring Session Event Listeners".

92.5 Accessing Indirection

As part of your general error handling strategy, your application should be prepared to handle a ValidationException of type ISOLATED_SESSION_IS_NO_LONGER_AVAILABLE.

TopLink throws an ISOLATED_SESSION_IS_NO_LONGER_AVAILABLE when a client triggers the indirection (lazy loading) on an isolated object when the isolated session used to load that object is no longer available, that is, after you call the isolated session method release.

Note:

Ensure that you have instantiated every relationship that you need prior to calling the release method: to instantiate a one-to-one relationship, call the get method; to instantiate a one-to-many relationship, call the size method on the collection.

Fore more information, see the following: