Lambda Handler missing about lambda-java8-dynamodb

[rabowskyb]

Each of the methods in the EventFunctions class serves as a Lambda handler. In other words, this code base can be used to generate 5 Lambda functions, one for each method/handler in that class.
To test, you can use the Lambda console to create a function for a method in EventFunctions, assigning that method as the handler. Then you can test the function using the Test Function tab in the console, or by invoking it another way (e.g. using the AWS SDK for Lambda, etc.).

[chetanmelkani]

@rabowskyb Thanks for clearing that out. I have a further query.
I see that you create singleton objects which use synchronized and volatile, but do we really need to handle concurrency in a lambda? Aren't the concurrent calls suppose to trigger a new instance of lambda? Couldn't we just make sure that the objects are created only once, that will facilitate the container reuse case?
Pardon me for asking this question here, but I looked all over and couldn't find a direct answer to my question and this really bothers me.

[rabowskyb]

A particular execution of a Lambda function corresponds to a container, which may be re-used across multiple invocations. Also, it is possible to use multithreaded code with a Java 8 Lambda function. For these reasons, plus to keep the code portable, it is a good idea to create singletons where you would otherwise do so outside the Lambda paradigm.

[chetanmelkani]

Reusing the container, makes sense and it has been described in the documents as well. But what I want to know is, if two concurrent requests would ever invoke the same lambda, either reusing the existing one or creating a new container? And let's take the case when the lambda function implementation is single threaded.
Because if the same lambda container is never called concurrently and also the lambda implementation is single threaded, then I guess it would be a good idea to remove concurrent handling from the code. Which is my use case.

[rabowskyb]

The last thing I can say about this is that it is a good idea to keep the singleton code in there, for two reasons: (1) to future proof your code, and (2) to keep your code portable. The performance impact of obtaining the lock for the synchronized block is negligible, and happens one time only when the container is first started.