What I did successfully, although it wasn’t in Dancer, was to create a wrapper-class that was used to carry out all DB operations. Internally, it wrapped all SQL operations in an eval { ... } block in order to trap errors. If an error was caught, it destroyed the existing database handle by attempting a courtesy disconnect, then setting the handle to undef, then attempted to reconnect. Everything was bulletproofed so that the object always maintained control and awareness of the present-state. All of this (fairly complicated) logic was wrapped-up in the methods of the object that the entire applicatioin used, in lieu of direct DBI-calls, to perform all kinds of database access. (All credentials, etc. were provided by private methods of that object so that secrets would not persist in memory.)

All credentials, etc. were provided by private methods of that object so that secrets would not persist in memory.

I can only pray that you know that that "private methods" have nothing to do with whether or not secrets are kept in memory or not. I hope that you're just really glossing over security details here, which is a questionable practice too - what if someone reads this and understands "private" methods to be some kind of real security measure?

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other