How to prevent from deadlock in Thingworx ?

[seanccc]

Hi, 

I wonder how the thingworx prevent from the deadlock ? 

Do I need to take care of the deadlock during developing the javascript service ? 

Does the Query* / Get* / Find* service of Thing generate SQL like select xxx for update ? 

Regards,

Sean

[zyuan1]

For your questions:

1. Deadlock does happen a lot in production environment if the Javascript is not carefully managed (long script, for loops, etc) . And if deadlock happens, the CPU will go high and Tomcat server down in a short time.  So to decrease that happening, carefully design the code, use some try catch block, leave some padding time between connected services and don't call the complex script too frequently.

2. the function are the same, and it searches data from the exact table in Persistence provider. Since Database like MSSQL and PGsql only accepts SQL command input, so yes, the API points to the Select commands

[CarlesColl]

Just my two cents:

• Cut in pieces long lasting service calls, what's long? 10minutes of execution it's kind to going to kill your server
• Build a queue system in order to control whats going on your system and also to control execution threads and load. Queue can allow you to cut in pieces long lasting services.
• Write message logs (with total time execution) tor services that you expect that can last long
• You never know what will be a long lasting service, why? you are dealing with remote connections (if you have edge connected devices with the SDK) and a remote service call can last a lot longer that what you expect.
• Reading properties doesn't causes locks, but of course trying to read a persisted property can cause a locking on this thread if someone else is writing on it.
• Lock on properties only are in place when writing on a persisted property, there isn't lock on memory only properties.
• Scarcely use Async services (or never)
• Again, build a queue system ;) that should be a standard feature on ThingWorx

[seanccc]

@CarlesColl 

Does the queue system you mean is the Event/Subscriber in Thingworx ? 

Regards,

Sean 

[CarlesColl]

No, I mean a queue system for executing services on a queue where you have control of what's going on, what's executing and what's going on in parallel and whats not.

[seanccc]

@CarlesColl ,

Do you mean something like ActiveMQ ? 

Sorry I don't know if thingworx has a built-in queue system,  for example, if I want several services get executed in serialization, how to do it in thingworx ? 

[seanccc]

@zyuan1 ,

Is it SELECT or SELECT ... FOR UPDATE ?  

If it's SELECT only, then the dead lock occurs if the purpose of SELECT is for Updating. For example: 

process A: SELECT * FROM purchases WHERE processed = false;
--- process B updates the data while process A is processing it
process B: SELECT * FROM purchases;
process B: UPDATE purchases SET ...;
process A: UPDATE purchases SET ...;

 If it's SELECT ... FOR UPDATE then it's possible to mitigate the above case . 

BEGIN;
SELECT * FROM purchases WHERE processed = false FOR UPDATE;
-- * application is now processing the purchases *

UPDATE purchases SET ...;
COMMIT;

Regards,

Sean