We have a situation where multiple, identical RPC requests can be submitted by users. Due to the nature of the front end (client) application it appears that the developers are unable to stop this from happening. This could possibly be solved by the use of a unique key on an ADABAS file to ensure that only one RPC is actually processed and the other fails with a non-unique descriptor value response code.
The following scenario is of concern to us as we need to make absolutely certain that we don’t end up with duplicate unique keys else the solution is useless.
- RPC calls are held up by a TTSYN (120 seconds) for an online backup and so two or more identical RPCs can be submitted by user due to frustration (WAIT timeout is 30 secs at the ESB which issues the RPC call on behalf of the client app).
- RPC A inserts unique numeric descriptor with value 1234. ie here we have an >after< value for the descriptor.
- The preceding transaction remains ‘open’; RPC A has not ET’d.
- RPC B attempts to add a record to the database with descriptor value 1234…
- RPC A then ETs
- RPC B ETs
To the best of my knowledge (I am happy to be corrected) the LDEUQP does not help here as it holds unique descriptor >before< images from deletes and updates in case the delete or update is backed out hence while the delete/update is in flight it is not possible to add a value to the UQ DE which in essence has not been committed as deleted/changed yet.
Does ADABAS manage the scenario described in the numbered list above? Is this managed by searching DB+LBP for descriptor values which exist there? I am afraid that I have never before used UQ DEs. However this would seem like the only way to stop our duplicate RPC transaction problem given the developer’s professed inability to prevent this situation arising.
An authoritative answer would be appreciated.