3 ms·
Another cool thing about this is it avoids the connection pool issue with Lambda (where concurrent requests cant reuse connections). Aurora is already pretty g
by cavisne 7y ago
Another cool thing about this is it avoids the connection pool issue with Lambda (where concurrent requests cant reuse connections).
Aurora is already pretty good at handling a lot of connections but this is even better.
- keysmasher 7y agoNot really, it was solved without this API given aurora serverless would manage connections and scaling automatically (https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...). But the real problem was connection time was unusable for any client facing application. I tried it after it was released (not preview). I really doubt this API would respond any faster.
- djhworld 7y agoYou can create a connection pool in a static context that lives throughout the lifetime of the JVM. Although admittedly if Lambda scales to multiple JVMs as request rate increases, you'll have multiple pools. Or if your request rate is low you'll not get much benefit
- cavisne 7y agoLambda containers serve 1 request at a time, so the number of JVM's tends to scale out a lot quicker than you would expect. This is more of a broader problem with Java on lambda, as the classic Java way of creating a bunch of singletons on startup and accessing them from multiple threads doesn't work, you just get a really slow cold start time and some near empty connection pools.