3 ms·

https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/ https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-... > Your function co

by karl_p 6y ago

https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-aws-lambda/ https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-... > Your function code is cleaner, simpler, and easier to maintain. I don't think your post covers the nuances. "Not a correct implementation"? We weren't trying for lowest latency, we were trying for highest reliability / simplest code / easiest to test. How do you test that your reused connections handle the "timed out right as next request comes in" case?

astuyvenberg 6y ago
I mean not correct in the literal sense. It's not about reliability nor simplicity nor testability - the code is wrong. It has a bug. The code is written without understanding that lambda containers can be re-used, thus, it's exhausting a finite resource unintentionally. You handle the "timed out right as next request comes in" case by memoizing the connection in a variable and checking if it's null in the handler. If it is, re-establish the connection.