At present, when creating/deleting any entity (Things, Valuestream etc.) programatically through CreateThing service does not return anything; which means the service is non-blocking. Maybe the actual creation of entity happens in some different thread. So if we are creating Things programatically in a loop, all things gets created in parallel without actually knowing if the first thing is created and committed to DB before creating the second thing.
This leads sometimes to getting errors of model access provider.
So if the Create/Delete thing returns something (maybe true false or thing Id sort), it would be easier to proceed and also it would help in preventing creation of Ghost Entities
If a service does not return anything, it does not mean the service is non-blocking. It might be that the service still runs synchronous, but it simply chooses not to return an output.
We would need to make sure that the actual code in the service is optimized for large batch things creation. Do you have a case that displays the behavior you mentioned (model access provider errors) ?
My only intention of saying that these types of services should be returnable and blocking, is because I am facing such issues of Model access Provider/Data access Provider in my application, for which I am already in touch with PTC, through e-support portal. Moreover these types of errors have huge impact on big solutions, as even we have to change quite a lots of code in our existing solution. Also these types of errors are moreover related to Data Base that we choose, so it is difficult to architect and predict such problems.
In fact I was also wondering, why is it so, that, Thingstart subscription is invoked even before the Thing is properly committed to DB.
Moreover if we are also consider the case of batch of large thing creation, it happens so that unless the service which is creating the large batch of things, exists, the created Things are not committed to DB. So if we try to do anything in Thingstart (like creating and setting the valuestream, or setting the description) it will give these errors. This behaviour is observed in Thingworx 8.4 prominently.
Thanks @amittal1 for creating this idea we face the same issues here. Have you already some news when this will be fixed?
Hi @aschultheiss Can you please open a case to Tech Support if you encountered this kind of issue? From what I can see this sounds like a bug and I believe the problem must be understood and replicated. What I'm saying is that before treating it as an enhancement we need to make sure it's not a bug - ideally we can solve this in a more proper way.
Thank you. But no plans to implement at this time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.