Object pool pattern - seperation of concerns - encapsulation: Who ist best to delete the instance?

- Situation

During a development I implemented the design pattern called object-pool-pattern. Basically this means, our class has a static public method and a static-protected attribute. This attribute carries all instances, which can be retrieved by the static public method, if a certain object-key is provided. For more information, let me know, I will provide more information. But in general I use the method, called "get_instance" to retrieve the instance into a local reference variable and then invoke other methods on it. In our case, a wrapping function module calls "get_instance", and later on, invokes some methods on that instance. In a particular case the lifetime of a certain instance ended. So, it has to be removed from the object pool. Until now I do it inside an instance-method, where the object deletes itself from the pool (a table).

- Assumption

The outer reference in the function module should have become invalid, because it does reference a not existing object. The garbage collector should now carry about this orphaned reference, If I assume correctly. ( In general this goes the other way around: A not referenced object is generally killed by the GC). In this case I still assume, that the local reference in my function module should also become collected. Because the object, it was referring to, was deleted from the object-pool. Nevertheless, until now, I still call "Free lr_myreference". A co-worker said, it might be better to implement a static public method, which would NOT act on the reference but simply killing the entry of the pool, prior to calling "Fee lr_myreference".

- Questions

In general I am thinking about: Which might be the responsive caller, to delete the object from the pool ? What about other local references referring to the entry in the table, which is the "original reference" ???