Failed Transaction: Work Assignment" has already been removed by another user
Hi Community,
We occasionally received the below failed transaction and I’m just curious to know why another user will remove “Work Assignment” without letting the other user know about it. This kind of failed transaction is caused by the system? Or how do we know which user removed the work assignment?
Failed Transaction
ERRINV: ORA-20115: JtExecutionInstance.The "Work Assignment" has already been removed by another user.
Thanks
Mesh
Page 1 / 1
Hi Community,
We occasionally received the below failed transaction and I’m just curious to know why another user will remove “Work Assignment” without letting the other user know about it. This kind of failed transaction is caused by the system? Or how do we know which user removed the work assignment?
Failed Transaction
ERRINV: ORA-20115: JtExecutionInstance.The "Work Assignment" has already been removed by another user.
Thanks
Mesh
Hi Mesh,
Can we know in which operation you observe this error? Is it something randomly pops up or when a user trying to execute any functionality in the application? It helps us to narrow down the cause of the issue. The issue can be occurred due to a permission related issue for a particular user. And if this error is for all users, we need some investigations before coming to a conclusion. There are some related issues reported previously and they were fixed through applying bug fixes.
Thanks and Best Regards, Tharindu
Hi @meshfemi,
This failed transaction error message is a bit misleading.
ERRINV: ORA-20115: JtExecutionInstance.The "Work Assignment" has already been removed by another user.
What it actually means is that during the database calls, the work assignment was not found in the DB. Usually the database function runs a cursor to check if this work assignment exists. It seems that when passing in the values to search for it, it cannot find this record in the DB. Therefore it is assumed that the work assignment has been removed and the error is thrown back to the client.
The possible causes are:
1) The most important: This is not the first failed transaction in chronological order. What happens is, if you face a failed transaction, all subsequent transactions are stuck in the queue. So in that case, if you are in UPD 13 and below, when you create a new work assignment from the mobile, it is still stuck in the queue and therefore when it tries to check in the DB there is no actual record in the database because the commit has never happened. So you need to resolve the first failed transaction in chronological order and that might resolve all the subsequent failed transactions automatically.
2) If it is the first failed transaction in chronological order or you are in UPD 14, then you need to open the debug console and re-process the failed transaction. In the server trace you should be able to find the method call along with the input binded variables. From this you can identify if the correct inputs are being passed in to the function call.
One good question to ask is, are you transferring work assignments to mobile or are you creating new work assignments from the mobile?
/Ibrahim
One good question to ask is, are you transferring work assignments to mobile or are you creating new work assignments from the mobile?
It could also be the case that you have accepted a pool task.
It would be helpful to know the “Method” for which the Failed Transaction was created. You can find this in FT Details.
Ex:
@Tharindu Rasnakawewa Thank you for your contributions. This error occasionally pops up when a user is trying to report a "Work Task" on their MWO.
Mesh
@Ibrahim Naazir Thank you for your explanation. yes, we have a seen a situation where previous failed transaction, for instance (ORA-20113: MobileSyncData.FND_LOCKED: The update could not be performed since the Mobile Sync Data record is currently locked) triggers this failed transaction in question and this is associated with UPD9.
This failed Transaction error usually occurred when a user is creating a New Work Assignment from MWO.
Mesh.
@Maithree, Next time I will pay attention to the same kind of failed transaction to see which "Method" the error was created.
Thanks for your help as well.
Mesh.
@meshfemi, do you have any custom events that were created? This failed transation should ideally be temporary, once the lock is released the failed transaction should resend!
Then all the transactions should resend successfully, if there are any that is still blocked then get the first (chronological) failed transactions from the one that fails.
/Ibrahim
thanks @Ibrahim Naazir for your contributions. Yeah, the FND_LOCKED failed transactions usually resend after 15mins. This failed transaction creates subsequent failed transactions when a user keeps processing transactions without waiting for this first transaction to resend and this is frustrating sometimes for users.
@meshfemi no problem! In that case if you keep experiencing this Fnd_locked failed transactions, I would suggest looking into why that appears. For a table to be locked it could mean other transactions trying to access mobile_sync_data_tab. Do you have any custom events running on any of the mobile entities?