worklight adapters, session variables: do multiple requests race?

Question

Question is: are adapters thread-safe?

We know that adapters can have session variables, so that state created by one call from a client is accessible on a subsequent call (assuming session affinity if we are using a cluster). An example question/answer here confirming that.

Given that client code is making asynchronous calls to adapters it's clearly possible for a client to issue multiple simultaneous requests to an adapter and hence there is a potential for a race condition between two such requests hitting the same session variables.

I see two possibilities (ignoring for the moment the issue of consistency between cluster members):

The Worklight Server might permit parallel requests to run in separate threads in which case if the session state variables have the potential for material inconsistency synchronisation will be required and we need to use Java constructs or a database to achieve whatever thread-safe logic we must implement.

The Worklight Server might queue requests for a session hence Adapters are thread safe (within a single process) and hence our code is somewhat simpler.

What does Worklight promise?

Answer 1

Here's what one of the Worklight architects says:

Worklight runs the requests in separate threads, where the global variables are accessible to all those threads as a shared Scriptable object. So technically, two concurrent requests from the same session updating multiple fields of the shared object may leave that object in inconsistent state.

However from the application logic point of view, it's a rare situation where an application sends concurrent requests updating the same data with different values. Usually it is an undesired flow and is prevented by the application on the client side (by using a busy indicator, etc...). If necessary, the developer can use simple sync constructs in the adapter code, like maintaining an "inProgress" boolean global variable, and reject an update request if inProgress == true.

If there is a real use case requiring synchronization, it would be interesting to learn it and maybe propose a different solution.