Community Tip - You can Bookmark boards, posts or articles that you'd like to access again easily! X
Hi,
In my customer's case, multiple requests may update different fields of a same record of Data Table . I use the service UpdateDataTableEntry to update the record, which means the whole record will be updated, will the second request overwrite the updated field value of the first request ? If so then the first request's data is lost .
The same question is also for Stream updating with the service UpdateStreamEntry.
Regards,
Sean
Solved! Go to Solution.
To set a lock, you only need to write on a persistent property and lock will happen.
Something like:
me.myLockPersistentProperty = "something";
Al threads will be locked, only the first one will pass, then the other, and the other,.... Mutex alike.
This is the theory, you will not find it written anywhere on Thingworx.
Yes on both cases it will overwrite the same entry, as you are telling it to do with UpdateDataTableEntry, also you can enter on locking conditions, and also if you query and update the same register at the same time you can have inconsistent results ...
To set a lock on the service UpdateDataTableEntry, can I use property as lock ? for example :
In the service UpdateDataTableEntryByField
1. if ( Thing["DeviceA"].LockStatus === 'Locked' )
then throw new Error("DeviceA is being updated, please try again later")
2. Thing["DeviceA"].LockStatus = 'Locked'
3. Thing["DataTable"].GetDataTableEntryByKey('DeviceA')
4. //Update the field value
5. Thing["DataTable"].UpdateDataTableEntry()
6. Thing["DeviceA"].LockStatus = 'UnLocked'
Set the property 'LockStatus' to be NOT persistent , I guess Thingworx server set thread lock on property , so it would be better than persistent property, at least for single Thingworx server.
Is it a feasible way to avoid data lost ?
Regards,
Sean
To set a lock, you only need to write on a persistent property and lock will happen.
Something like:
me.myLockPersistentProperty = "something";
Al threads will be locked, only the first one will pass, then the other, and the other,.... Mutex alike.
This is the theory, you will not find it written anywhere on Thingworx.