All Known Subinterfaces:: MemoryContext, ResourceOwner

public interface Lifespan

Model of any notional object in PostgreSQL or PL/Java that has a definite temporal existence, with a detectable end, and so can be used to scope the lifetime of any PL/Java object that has corresponding native resources.

A Lifespan generalizes over assorted classes that can play that role, such as PostgreSQL's ResourceOwner and MemoryContext. MemoryContext may see the most use in PL/Java, as the typical reason to scope the lifetime of some PL/Java object is that it refers to some allocation of native memory.

The invocation of a PL/Java function is also usefully treated as a resource owner. It is reasonable to depend on the objects passed in the function call to remain usable as long as the call is on the stack, if no other explicit lifespan applies.

Java's incubating foreign function and memory API will bring a ResourceScope object for which some relation to a PL/Java Lifespan can probably be defined.

The history of PostgreSQL MemoryContexts (the older mechanism, appearing in PostgreSQL 7.1), and ResourceOwners (introduced in 8.0) is interesting. As the latter's README puts it, The design of the ResourceOwner API is modeled on our MemoryContext API, which has proven very flexible and successful ... It is tempting to consider unifying ResourceOwners and MemoryContexts into a single object type, but their usage patterns are sufficiently different ...."

Only later, in PostgreSQL 9.5, did MemoryContext gain a callback mechanism for detecting reset or delete, with which it also becomes usable as a kind of lifespan under PL/Java's broadened view of the concept. While not unifying ResourceOwners and MemoryContexts into a single object type, PL/Java here makes them both available as subtypes of a common interface, so either can be chosen to place an appropriate temporal scope on a PL/Java object.

Interface Lifespan