我们如何将JDBC连接池与AWS Lambda结合使用?

否.从技术上讲，您可以在处理程序函数之外创建一个连接池，但是由于每次调用只能使用一个连接，因此您要做的就是捆绑数据库连接并分配一个池，您只能使用1

No. Technically, you could create a connection pool outside of the handler function but since you can only make use of any one single connection per invocation so all you would be doing is tying up database connections and allocating a pool of which you could only ever use 1.

将Lambda函数上载到AWS之后，第一次调用它时，AWS将创建一个容器并运行设置代码(创建池的处理程序函数外部的代码-假设是N个连接)，然后调用处理程序代码

After uploading your Lambda function to AWS, the first time it is invoked AWS will create a container and run the setup code (the code outside of your handler function that creates the pool- let's say N connections) before invoking the handler code.

下一个请求到达时，AWS可能会再次使用容器(也可能不会).通常会使用容器，但这取决于AWS，不受您的控制.

When the next request arrives, AWS may re-use the container again (or may not. It usually does, but that's down to AWS and not under your control).

假设它重用了容器，您的处理程序函数将被调用(设置代码将不再次运行)，并且您的函数将使用N个从池中连接到数据库的连接之一(已保留)在容器级别).这很可能是来自池的第一个连接，编号为1，因为可以保证它不会被使用，因为两个功能无法在同一容器中同时运行.继续阅读以获取解释.

Assuming it reuses the container, your handler function will be invoked (the setup code will not be run again) and your function would use one of N the connections to your database from the pool (held at the container level). This is most likely the first connection from the pool, number 1 as it is guaranteed to not be in use, since it's impossible for two functions to run at the same time within the same container. Read on for an explanation.

如果AWS不重用该容器，它将创建一个新容器，您的代码将分配N个连接的另一个池.根据容器的周转情况，您可能会完全耗尽数据库池.

If AWS does not reuse the container, it will create a new container and your code will allocate another pool of N connections. Depending on the turnover of containers, you may exhaust the database pool entirely.

如果两个请求同时到达，则AWS无法同时调用同一处理程序.如果可能的话，您将在容器作用域级别定义的变量遇到共享状态问题.相反，AWS将使用两个单独的容器，并且每个容器都将分配一个N连接池，即与您的数据库的2N连接.

If two requests arrive concurrently, AWS cannot invoke the same handler at the same time. If this were possible, you'd have a shared state problem with the variables defined at the container scope level. Instead, AWS will use two separate containers and these will both allocate a pool of N connections each, i.e. 2N connections to your database.

单个调用函数不需要多个连接(当然，除非您需要在同一上下文中与两个独立的数据库进行通信).

It's never necessary for a single invocation function to require more than one connection (unless of course you need to communicate to two independent databases within the same context).

连接池唯一有用的时间是它在容器范围之上，即由AWS环境本身传递给容器.这是不可能的.

The only time a connection pool would be useful is if it were at one level above the container scope, that is, handed down by the AWS environment itself to the container. This is not possible.

您可以希望的最佳情况是每个容器有一个单个连接.即使这样，您也必须管理该单个连接，以确保数据库服务器没有断开连接或重新引导.如果是这样，除非您在函数中编写了一些代码来检查断开的连接，否则容器的连接将终止，并且处理程序将永远无法再次连接(直到容器终止).在繁忙的服务器上，容器可能需要很长时间才能消亡.

The best case you can hope for is to have a single connection per container. Even then you would have to manage this single connection to ensure the database server hasn't disconnect or rebooted. If it does, your container's connection will die and your handler will never be able to connect again (until the container dies), unless you write some code in your function to check for dropped connections. On a busy server, the container might take a long time to die.

还请记住，如果您的处理程序函数失败(例如，在事务进行中途失败或锁定了表)，则下一个请求调用将从容器中获取脏连接状态.第一次调用可能已打开事务并死亡.第二次调用可能会提交并包括所有之前的查询，直到失败为止.

Also keep in mind that if your handler function fails, for example half way through a transaction or having locked a table, the next request invocation will get the dirty connection state from the container. The first invocation may have opened a transaction and died. The second invocation may commit and include all the previous queries up to the failure.

除非您有特殊的需要，否则我建议根本不要在处理程序功能之外管理状态.如果这样做，则使用单个连接，而不是池.

I recommend not managing state outside of the handler function at all, unless you have a specific need to optimise. If you do, then use a single connection, not a pool.