Caching P-ties

Releasing all p-ties at the end of every operation appears unreasonable, since the ODA only needs to ensure that these p-ties will be eventually released. Postponing their destruction would avoid the costs of successive p-tie reinstantiations. Our ODA implementation actually caches the last $N$ p-ties it instantiated, where $N$ is a configurable parameter. At the end of every operation the ODA brings the number of p-ties down to $N\; +\; \delta$, keeping the most recent ones. (The $\delta$ accounts for any duplicate calls that might have been issued by the server code.)

Caching p-ties makes sense if the ODBMS ensures that their d_Ref data members remain valid across transactions. So far we have ignored database transactions, this topic will be discussed in Section 4. Let us assume, by now, that transactions are started and committed (or aborted) by means external to the CORBA server, and that each operation is encompassed by an individual transaction.

Does a d_Ref from transient to persistent memory retain its validity across transactions? The ODMG standard leaves the answer to the discretion of the ODBMS implementor. In most ODBMSs, such a reference cannot be used in between transactions, but does remain valid across transactions. This being the case, the ODA should cache p-ties.

With caching, the CORBA server must have a way of forcing the removal of objects from the cache. Accordingly, the ODA provides a function that receives a CORBA::Object_ptr and immediately deletes the corresponding p-tie. This function, ODA::Delete, is intended to be called by destructors of persistent implementation objects, with the purpose of avoiding dangling p-ties.