Actually, there at at least two things wrong with letting a dbms perform session garbage collection.
The first is assuming a definition for "session garbage collection." The second is assuming that the dbms will always keep that definition in spite of its evolution. Garbage collection is defined by the person who makes up the phrase. I would love to see the transcripts of meetings where manufacturers of object oriented programming languages tried to define garbage collection. I have no doubt it was more than a single one hour meeting. At least in the case of Oracle, garbage collection for sessions that don't properly disconnect is a problem. Just consider this one simple case of an Oracle application: The DBA defines a maximum number of sessions that can be connected at any one time. This is mandatory depending on the customer's Oracle license. The application chugs along just fine until one day when the workload increases such that the number of sessions connecting and "disconnecting" cause and it throws and ORA-00018: maximum number of sessions exceeded. But the application was architected to never surpass the maximum defined by the DBA. What's wrong? Sessions aren't cleaned up quickly enough to allow new ones to instantiate. Sessions defined as "garbage" must be cleaned up by Oracle's background processes, pmon or smon, depending on the circumstances. The amount of time required to clean up a "garbage" session varied greatly depending on its last known state. Nobody in the application development group had accounted for any of that response time. When the application was modified to perform a proper disconnect two things happened: 1. The application stopped throwing the ORA-00018 error 2. The CPU consumption for pmon and smon dropped significantly
