This method automatically invoked by PicoContainer and deregisters JDBC drivers, which were forgotten.
Dynamically loaded JDBC drivers can not be simply used and this is a well known problem of DriverManager
,
so workaround is to use proxy.
However DriverManager also contains memory leak, thus not only proxy, but also original driver must be deregistered,
otherwise our class loader would be kept in memory.
This operation contains unnecessary complexity because:
- DriverManager checks the class loader of the calling class. Thus we can't simply ask it about deregistration.
- We can't use reflection against DriverManager, since it would create a dependency on DriverManager implementation,
which can be changed (like it was done - compare Java 1.5 and 1.6).
- So we use companion -
JdbcLeakPrevention
. But we can't just create an instance,
since it will be loaded by parent class loader and again will not pass DriverManager's check.
So, we load the bytes via our parent class loader, but define the class with this class loader
thus JdbcLeakPrevention looks like our class to the DriverManager.