Handling parallel REST post requests

Question

I have created my own REST service based on the examples from "Domino Sample REST Service Feature" from 901v00_11.20141217-1000 version of XPages Extension Library.

As far as I understand the design of the library each REST request will be run in its own thread on the server. This approach does not allow to handle parallel POST requests to the same document.

I have not found any examples in XPages Extension Library which would handle post requests as transactions on the server, i.e. which would block the server resource for the whole request processing time and would put put next requests in the queue?

Can anybody point to the source code of the service which would allow to handle parallel requests?

The skeleton for my post request processing function is this

@POST
@Path(PATH_SEPARATOR + MyURL)
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public Response myPost(
  String requestEntity,
  @Context final UriInfo uriInfo)
{
  LogMgr.traceEntry(this, "myPost");

  RestContext.verifyUserContext();

  String myJson = ... // Process post

  Response response = buildResponse(myJson);

  LogMgr.traceExit(this, "myPost", "OK");

  return response;
} 

And I would like to implement something like this

// Start transaction

String myJson = ... // Process post

// Stop transaction

Is there a way to do it in Java?

Answer 1

I suppose you could use document locking in traditional Notes/Domino context - and synchronized in Java :-)

Have you tried any of these? I cannot see why they should not work.

/John

Answer 2

I agree with John. You can use document locking to prevent simultaneous updates to the same document. You might also want to consider some changes to the definition of your REST API.

First, you imply you are using POST to update an existing document. Usually, POST is used to create a new resource. Consider using PUT instead of POST.

Second, even with document locking, you still might want to check for version conflicts. For example, let's say a client reads version 2 of a document and then attempts to update it. Meanwhile, another client has already updated the document to version 3. Many REST APIs use HTTP ETags to handle such version conflicts.