Ik denk niet dat het thread-safe maken van databaseverbindingen een gangbare praktijk is. Meestal is wat je wilt:
- Serialiseer de toegang tot een deel van uw servlet, zodat er niet meer dan één servlet tegelijk code uitvoert (bijv. door het
SingleThreadModelte implementeren interface). - Een bepaalde tabel / tabelpagina / rij vergrendelen zodat u op een bepaalde tuple kunt werken (door het isolatieniveau van de database te wijzigen).
- Optimistische vergrendeling gebruiken om gewijzigde rijen in een tabel te detecteren (met behulp van een referentiekenmerk van de tabel om te controleren of de huidige versie dezelfde is als die in de tabel).
AFAIK, het typische gebruik van ThreadLocal<Connection> is om een unieke databaseverbinding per thread op te slaan, zodat dezelfde verbinding op verschillende manieren in uw bedrijfslogica kan worden gebruikt zonder dat u deze telkens als parameter hoeft door te geven. Omdat de implementatie van de gemeenschappelijke servletcontainer een thread gebruikt om aan een HTTP-verzoek te voldoen, zullen twee verschillende verzoeken gegarandeerd twee verschillende databaseverbindingen gebruiken.