Description
We are using Spring session 2.0.5.RELEASE. We are using JDBC session persistence.
We have migrated those applications that were previously using container in memory session (Wildfly/Undertow). The code has stayed as-is.
We have html pages that fire up multiple calls in AJAX simultaneously to a controller.
In the controller we have code that set an attribute into the session.
The issue is that multiple threads of the application server are busy in parallel treating those AJAX calls, the first thread will insert the new attribute in the database. The other threads are then supposed to call an update of the attribute in the database because the attribute already exists. But the issue is that the other threads have not detected (yet) that the attribute already exists and try to do an insert as well resulting in a duplicate key exception.
I must say that as a workaround we have patched the application to do a sort of initialisation AJAX call at page load and this initialisation just set the attribute with a blank value, this allows the attribute row to be created and when further calls are being made in parallel, the JDBC implementation of Spring session sees that only updates are needed.
However I wanted to report this in order to support those use cases natively (without workarounds) using JDBC persistence.