Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Sling Post Servlet 500 Error with Rapid Requests or Slow Network

Avatar

Level 4

We're trying to use the SlingPostServlet to save content to a page when an author interacts with various input. For example, we have a checkbox in the authoring environment that will post it's "checked" status every time it is clicked. This works well, except when the user clicks the checkbox rapidly or if the network is sluggish. This causes two or more requests to go out to the same node and at least one of the responses will return a 500 internal server error with the following message -

org.apache.sling.api.resource.PersistenceException: Unable to commit changes to session.

I'm assuming this is happening because the node is locked by the first request when the second request tries to alter the value. Is there any easy way to get around this from the server side? The only solution i've thought of is to use javascript and build a queueing system for the requests on the client side so we only allow one request at a time, but it makes me nervous to queue up data like that.

Thanks

1 Accepted Solution

Avatar

Correct answer by
Level 9

Do you have clustered enviroment? if so, you can look at the following post

http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

What happens is when you are continuously hitting it makes a server call which calls session.save for each hit. Some how if you have network problems or not enough gap between the request, this creates a conflict with previous request. Resulting in this exception.

View solution in original post

2 Replies

Avatar

Correct answer by
Level 9

Do you have clustered enviroment? if so, you can look at the following post

http://help-forums.adobe.com/content/adobeforums/en/experience-manager-forum/adobe-experience-manage...

What happens is when you are continuously hitting it makes a server call which calls session.save for each hit. Some how if you have network problems or not enough gap between the request, this creates a conflict with previous request. Resulting in this exception.

Avatar

Level 4

Thanks, we're only running one author server so this isn't applicable to our situation. I'll most likely end up writing the queue system in javascript so only one request goes out at a time.