A wonderful conceptual library cache model is the traditional library. Let's say you want to find Ray Bradbury's book, Dandelion Wine. Because the library is a massive storehouse of books (think all library cache objects), sequentially or randomly searching would be futile. So you go the card catalog area (think hashing structure) and walk directly to the card catalog containing books pertaining to authors whose last name start with the letters A through D (think hashed to a specific bucket). There is someone in front of you, so you must wait (think acquiring the related hash bucket's latch). Finally, you are in front of the appropriate card catalog (think acquired the latch), and begin sequentially searching for the book (think sequentially searching a hash chain). Finally, you find the card and see the book's address 813.54 (think library cache handle). You walk over to where the book should be, find it, and start reading (think accessing the cursor). If you can picture in your mind this story, you are well on your way to understanding Oracle's library cache.

As with the buffer cache, the library cache objects are located using a hashing algorithm. This involves a hash function, buckets, chains, and latches or mutexes. One key difference is the hash chain nodes are not composed of buffer headers, but rather simple pointer nodes called handles.

Handle is common term for a memory address pointer, and this is the case with the library cache. There is a one-to-one relationship between a handle and a library cache memory object. So referring to a handle is synonymous as referring to its associated object. When mutexes are used instead of library cache latches, each individual handle has an associated mutex. Each library cache object refers to an object of a specific type, sometimes called a namespace, such as a cursor, a child cursor, a table, or a programmatic construct.