Caching the db connection may not work depending on your DB driver. A possible scenario is:

* Cold start, connection is established.

* Code runs and returns.

* Lambda stops the process entirely but retains the container.

* DB detects the socket is closed and kills the connection.

* Warm start.

* Code runs and fails because the connection is invalid.

After they fix VPC cold starts (the ENI issue) I hope we get Lambda lifecycle events. onDestroyed, onFrozen, onThawed, etc. You kind of get onCreated now if you put the code into global scope but that's gross

The OP commenter said that the cache would have to contain retry logic, which in your sceanrio would trigger and then initiate a new connection object.

Yeah, I should have been clearer, it's not that it can't be done, it's just a bit messier than it seems at first blush.

The issue is that actions taken by stateful clients can't always be retried.

You can detect these kinds of errors, but it's klugey because these drivers generally assume that sockets dying is relatively uncommon, and it's painful to test this behavior when FaaS doesn't give you direct control over it.

So you typically wind up either with a proxy, or you decorate any handlers to refresh the connection ahead of time to make sure you have a fresh object.

I agree with you that it's messy and an anti-pattern to try to implement something like this in lambda.