When I worked on the Interchange Online Network for Ziff Davis (and later for AT&T), we wanted to offer implicit persistence. On the other hand, for some objects, we did not want to take the chance that the object would be swapped out to the database since we needed lightening fast access to the object. We needed to be able, on demand, to overrule the implicit persistence.
The database team decided to retain objects in memory with two types of pointers: a locker or a holder. A locker locked the object in memory and the programmer was required to unlock the object when he was done with it. This was not used often, but it did solve the problem of instant access. Unlocking the object caused it to be written back to the database. Lockers implemented explicit persistence.
A holder, on the other hand, was a proxy for the object, which was taken out of persistence and returned to the object store at the instigation of the object store itself. The goal was to have the object in memory when it was needed, but to be able to clear it out of memory when memory was scarce. This form of implicit persistence was a powerful mechanism of encapsulation, as the programmer could use the holder as if it were the object, without regard as to whether or not the object actually was in memory. If he needed to ensure the object would have optimal performance, he could lock the holder (changing it into a locker) and when he was done, he could unlock the locker, turning it back into a holder.
As an aside, we had to override the pointer operator (
) to refer to the held (or locked) object, and the dot operator (->
) to refer to the holder or locker itself. Thus the holder (or locker) acted as a smart pointer. We added reference counting, so that if multiple holders (or lockers) referred to the same object, only one instance had to be kept in memory. .
In an object-oriented database that supports true implicit persistence, the programmer would not be aware of these issues. He would not differentiate between the proxy (holder or locker) and the object itself; as far as the programmer is concerned, the object is in memory when used, and in the database when not in use.