We are facing unexpected behavior of Async service when called from sync service.
While calling Async thingworx service, database related operations were not functioning well when called from sync service after logging entry in Data table. When async service tries to fetch the entry from data table using primary ID, no result is getting returned.
Sync service A adds entry in data table and calls Async service B (pass primary ID of same data table entry) for further processing of request.
But this seems to be working windows platform and issue encountered on linux ONLY.
As per the understanding, this could be due to the way platform handles multi-threading as async execute on separate thread or may be accessing data table before commit operation pf previous update.
Please let us know in case anybody faced this issue and what all options resolutions are available.
Just to update that we have analyzed further on this issue and tried to reproduce the same issue on local Linux VM using same client VM configuration and things are working fine.
I am not sure what exactly the issue is and there might be some difference in the installed packages. We are still working on this and update further on this thread if I get some more details.
You are facing what you are saying here:
"As per the understanding, this could be due to the way platform handles multi-threading as async execute on separate thread or may be accessing data table before commit operation pf previous update."
As async operation it's executed before you sync process ends ( the transactions start when your services starts and ends when your service ends ).
Hello Carles Coll,
On client VM (RHEL 7.2 version, 64 bit arch), using one service I am inserting a data in data table and using async to retrieve the already inserted record using the same ID, I am not able to perform or fetch the data entry made sync service and getting message that record doesn't exist.
This works well when tested locally on windows platform but facing issue when the same is deployed on Linux VM. My understanding was that this could be due to different platforms multi-threading capability.
But another update provided above as per further analysis, this problem is not due to different platforms and everything is working fine even with linux VM when tested locally. There might be some difference in installed packages on both the Linux VMs.
I am still analyzing this and I am not sure what exactly is the problem. It could be configuration differences.
You never know when a async process will be called ( at the same time, after, sometimes at the same time some times after,..), then it may act differently depending on the platform, but you should avoid this kind of situation, it's a shame but you will need to execute it synchronously or put on a queue ( there's no queues system on TW you will have to build your own or import a queue system as an extension ).
Synchronous execution is not the way because we expect large processing and to avoid long wait time for client.
Also, we are using database (Data table) queue for scheduler to handle failed requests.
I am not sure how queue solution will work here then !!
Could you please provide some details how this solution will solve the problem.
Put the async operation on your own queue where you control the execution ( for instance delay the execution half a second or alike ), on this queue you can check if data it's persisted and if not, you can requeue the operation for instance if info it's not ready, I don't know your logic...
Thanks Carles Coll,
As per our logic, we want to log requests in data table queue so that failed requests (due to internal error or server failure) can be re-tried at some later point of time and we don't lose any business data.
I agree, queue system can resolve access problem but queued requests will be stored in-memory only and can be lost in case of server failure.