Sure we can, if serialization is not an issue. What Oracle has done is to reduce the likelihood of requiring serialized library cache access by providing each session with its own private library cache-like structure containing just the session's popular cursors (actually just the pointers to the cursors, which are their handles). Because the cursor cache is private, serialization is guaranteed, and therefore, no control structure is required! This is an elegant solution indeed.

This private library cache-like structure is called a session cursor cache. By default, every session has a cursor cache containing pointers to its popular cursors. By default, Oracle Database 10g Release 2 caches 20 cursor pointers. In Oracle Database 11g Release 1, the default is 50 cursor pointers. Regardless of the defaults, the cache size can be modified at the system level (not the session level) by altering the session_cached_cursors instance parameter.

It works like this: When running a SQL statement, the session creates the statement's hash value, and then checks if that handle resides in its own cursor cache. Since no other process can access the session's cursor cache, no control structure is required. If the handle is found, the session knows the cursor exists in the cache. If the cursor is not found in the session cursor cache, the hash value is hashed to a library cache hash bucket, the appropriate control structure acquired, and then the chain is sequentially scanned, looking for the cursor. If the handle is found in the session's cursor cache, some effort has been expended parsing, but it's not as much as a hard parse (statement not found in the library cache) or even a soft parse (statement found in the library cache), and hence the term softer parse is used to describe this approach.