Process does not read inserted data in frequent request

I have a Process which Insert/Updates the record in entity "PQR". This process is triggered, when a new row is added in an entity "ABC".

The Process Insert/Update operation works as below: 

1. If an EmployeeCode added in the entity ABC is NOT present in the entity PQR then Insert in PQR

2. If an EmployeeCode added in the entity ABC is present in the entity PQR then Update the record in PQR.


Issue:

The calls to the Process are frequent. 

Let say the process has been triggered in an interval of 2 secs. 

The first call to the process checks for the EmployeeCode entry in PQR and finds that there is no record so moves ahead with the following assignment statements to Insert the data in PQR. 

Meanwhile second call to the process triggers which checks for the same EmployeeCode entry in PQR and finds that there is no record so moves ahead with the following assignment statements to Insert the data in PQR.  

Because of which the Process is creating duplicate entries in entity PQR. The second call to the process should have been updated the record, in order to maintain unique EMployeeCode in PQR entity.


I am not sure about the database table locks to be used here, so that second call to the process waits till the first process call release the lock on an entity.

Any suggestion please!!


Thanks in advance!

Solution

Hi, you can add status indications to the PQR entity, such as added, processing and processed. This lets you determine what the appropriate action should be, update or ignore. Also you can set database constraints to let the EmployeeCode be unique in table PQR so that duplicate entries will never be created. 

Solution

Bas de Jong wrote:

Hi, you can add status indications to the PQR entity, such as added, processing and processed. This lets you determine what the appropriate action should be, update or ignore. Also you can set database constraints to let the EmployeeCode be unique in table PQR so that duplicate entries will never be created. 

Thanks!