Node Getting Overridden while writing to Node

[bishnu_satpathy_tcs]

Hi Team

I am updating  nodes' properties through a post servlet.

But observing that when simultaneous requests are coming, it's overriding the node.

So when the node is being updated it doesn't get locked or blocked in AEM and hence other requests are find this as an available node which can be updated.

I have tried making the post method synchronized, but that's not helping either.

Could you please suggest a solution for this.

Regards

Bishnu

[arunpatidar]

If you use a single session then JCR will lock the parallel operation of same node.

Can you please explain the usecase here?

[bishnu_satpathy_tcs]

Thanks for the response @arunpatidar .

On further analysis we found the issue may be different.

following is the use case.

1. The client could not provision a Data Base and we were asked to maintain the data in AEM.

2. Now that we have long list of nodes containing data, we exposed an API to other team to update the node properties. 

3. Upon receiving the request through servlet we query the list based on unique property and update the node based on availability. And upon successful node save we performed reverse replication to sync the publishers.

4. Now we have realized that when multiple requests come to the server, it is going to different Publisher and updating nodes based on availability. Post that it replicates hence the issue of overriding nodes are happening.

We know a DB is recommended for these operations but we are trying to get a workaround through AEM.

Regards

Bishnu

[Jörg_Hoh]

Why are doing these operations towards a publish instance? 

[bishnu_satpathy_tcs]

Hi @Jörg_Hoh 

Could you please suggest, how should we approach for this requirement.

Regards

Bishnu

[Shashi_Mulugu]

@bishnu_satpathy_tcs May I know what kind of data we are storing in AEM here?

Based in the original post, and the responses you gave, your requirement falls on UGC but the content/nodes you store should always be unique structure. If you follow a common node structure, there is definitely override of data as parallel systems can update same nodes with different data, and when it gets reverse replicated to author, latest published one will take the cake.

[bishnu_satpathy_tcs]

Hi @Shashi_Mulugu 

Thanks for responding.

we have a list of unique consumable items for the end user on our application. This list of items have unique id.( e.g. we can consider list of seats in a cinema. -- typically the way a table stores the data with unique key).

These we were trying to store in aem nodes with that unique ids.

This is where we are facing issues in solutioning.

For these end user consumable items, what approach can be taken up.

Regards

Bishnu

[Jörg_Hoh · Accepted solution]

Basically you are facing the problem of concurrent writes, and you need to handle that situation on your own. The typical approach is handle failing writes and trying to repeat the operation. Depending on the load on the system and the level of parallel writes up to 3 tries can be sufficient, but it can also continue to fail every now and then.

In that case you need to switch to a different strategy and you need to synchronize the writes like this:

synchronized (lockobject) {

  resourceresolver.refresh();

  dothewrites();

  resourceresolver.commit();

}

the refresh is important.

[bishnu_satpathy_tcs]

Thanks @Jörg_Hoh 

Any suggestion or work around to handle a data base scenario in aem.

The scenario that I explained in previous comment.

https://experienceleaguecommunities.adobe.com/t5/adobe-experience-manager/node-getting-overridden-wh...

Regards

Bishnu

[Jörg_Hoh]

So if I understand your original question correctly, you have concurrent updates to the same node (triggered externally, using the SlingPostServlet), and that the result might be "incorrect".

This is something you cannot really handle from an AEM perspective. If implemented correctly (as outlined above), the last write wins. AEM cannot know the order in which concurrent writes have to be serialized, only the calling system can know that.