0

Consider that our application has some configs that user set them, and we need to have a backup of those data in order to restore them later.

Configs are list of different Objects and I have created some web services for each List of Object and application calls them in a chain, it means that with getting success response from one service they call the next one.

Now what the problem is...

I need to store each services data somewhere and after finishing the last service call in front end, I will create the final Object with received data from client and persist it in database(here MongoDB).

What is the best way for implementing this strategy?, consider that I don't want to persist each List of Object per service, I need to persist whole Object once.

Is there any way for storing body of a request somewhere until other services to be called?

What is the best for that?

I will appreciate any clue or solution that help me!

Sobhan
  • 1,280
  • 1
  • 18
  • 31
  • @kavithakaranKanapathippillai yes I think i am looking for something like what you mentioned but, 1)I need to implement it in server-side and not frontEnd 2)I will get my required data in several requests that come to server and yet I don't know where should i keep them until data become complete. what i understand from this pattern is that whole process can be done in one single request and create an error response or success response for client but what i am looking for occurs in several requests – Sobhan Jul 06 '20 at 05:03

2 Answers2

1

BEST WAY:

store all objects in client side and send only one request to server. it reduces resource usage of server side.

ALTERNATIVE:

if you realy want to handle it by several requests (which I do not recommend it) then one strategy is : store objects of each request by an identifier related to that session (best candidate is JSESSIONID) to a temporary_objects_table and after final request store it in main tables. and in failure of any service for that session, remove records with that sessionid from temporary_objects_table. it has much more complexity comparing first approche.

Ali Dahaghin
  • 77
  • 1
  • 11
0

After some research I found my answer:

REST and transaction rollbacks

and

https://stackoverflow.com/a/1390393/607033

You cannot use transactions because by REST the client maintains the client state and the server maintains the resource state. So if you want the resource state to be maintained by the client then it is not REST, because it would violate the stateless constraint. Violating the stateless constraint usually causes bad scalability. In this case it will cause bad horizontal scalability because you have to sync ongoing transactions between the instances. So please, don't try to build multi-phase commits on top of REST services.

Possible solutions:

  • You can stick with immediate consistency and use only a single webservice instead of two. By resources like database, filesystem, etc. the multi phase commit is a necessity. When you break up a bigger REST service and move the usage of these resources into multiple smaller REST services, then problems can occur if you do this splitting wrongly. This is because one of the REST services will require a resource, which it does not have access to, so it has to use another REST service to access that resource. This will force the multi phase commit code to move to a higher abstraction level, to the level of REST services. You can fix this by merging these 2 REST services and move the code to the lower abstraction level where it belongs.
  • Another workaround to use REST with eventual consistency so you can respond with 202 accepted immediately and you can process the accepted request later. If you choose this solution then you must be aware by developing your application that the REST services are not always in sync. Ofc. this approach works only by inner REST services by which you are sure that the client retry if a REST service is not available, so if you write and run the client code.
Sobhan
  • 1,280
  • 1
  • 18
  • 31