ThingWorx Edge Java SDK > Working with Things > The State of Things
The State of Things
A remote thing can preserve its state if the ThingWorx platform shuts down and restarts. In addition, a remote thing can take action when its state changes. This action can consist of generating notification events for runtime listeners or executing code to respond directly to these changes.
The state of a thing consists of all its property values. A remote thing in the ThingWorx platform is updated when it receives new property values from the client application that is running on the remote device. The remote thing holds its state in memory. If the server is shut down, this memory is discarded. When the server starts again, this remote thing is re-initialized, using the default values of its properties, unless the properties are marked with the isPersistent aspect. In this case, the current state of the remote thing is stored in the database when it is updated, allowing these values to be used instead of the default values when the remote thing is re-created on server restart.
In the Java SDK, a VirtualThing represents the state of a thing in the application and does not benefit from the isPersistent feature. Its job is to store the state of a device/machine on the remote machine.
Your client application is responsible for updating the state of this virtual thing. This state sits on the remote system until it is either pushed to the ThingWorx platform or pulled as a result of a request made by the server. A value cache on the server controls the push and pull processes.
The value cache stores all states reported to the server (values pushed to the server by a client application). You can designate whether the properties are cached forever, cached for a set amount of time, or not cached at all. If you refer to one or more properties in a mashup, for example, the state is delivered to your browser. That state is determined by retrieving the values of the properties from the local database of the server, unless some of those properties are bound.
Bound properties must be evaluated. If a property is bound to a remote thing, that value is stored in the value cache when the remote VirtualThing pushes it there. A timeout setting is applied to cached values. If the timeout period has not expired when a bound value is requested, the cached value is returned to the mashup.
Now consider a last cached value whose timeout period has expired. To evaluate the binding, the server must send a request to the remote system (if it is currently connected). This request pulls the current state of the corresponding VirtualThing from the remote system into the cache, forcing it to update. This process provides the latest value, but it can be slow and it can fail, so this behavior is not the default. You may have seen these settings in a remote thing configured on a ThingWorx platform.
The following figure provides an example of a Properties page and highlights properties that are bound as well as properties that are not bound. It also highlights cached values and properties for which the isPersistent, isReadOnly, and isLogged aspects are set (or not):
Properties of a RemoteThing
ThingWorx Composer, showing bound/not bound properties, cached values, and aspect settings for an Aquaponics Thing.
Note the differences between properties that are bound and those that are not. Any remotely bound property has the additional settings shown in this figure. The settings allow you to control the caching as well as the push and pull behaviors of each property that is bound to a value in the cache. The Data Change Info tab allows you to control how or even if the cache is used. Here is a closer look at this tab: