Le infotable vengono memorizzate nella cache come oggetto singolo. Per questo motivo, la manipolazione diretta delle infotable non è supportata in ThingWorx 8.5 e versioni successive in quanto può causare problemi di prestazioni e comportamenti imprevisti. Quando si recupera una proprietà infotable da un oggetto, viene creato un oggetto proxy che rimanda all'oggetto originale. Le modifiche dirette si verificano solo per la copia locale e l'oggetto originale viene aggiornato con le chiamate di funzione. Se è necessario un clone completo dell'oggetto in modo che le modifiche non vengano inviate al proxy fino a quando non sono aggiornati tutti i dati, utilizzare l'opzione di clone della risorsa. Negli esempi riportati di seguito per le infotable a riga singola viene utilizzato un oggetto wrapper, mentre per le infotable a più righe viene utilizzata l'opzione di clone completo, in quanto non si ha necessità di aggiornare ogni modifica di riga.

L'esempio seguente crea un oggetto proxy locale (le chiamate al metodo aggiornano l'oggetto originale e salvano nella cache):

L'esempio seguente crea un clone completo e le modifiche non vengono inviate nuovamente al proxy nell'oggetto originale:

I dati delle proprietà in ThingWorx 8.5 e versioni successive vengono trattati in modo diverso rispetto alle release precedenti. Tutti i dati vengono ora memorizzati in un livello della cache per consentirne l'utilizzo in locale o in remoto in un ambiente di clustering a disponibilità elevata. Negli ambienti precedenti i dati memorizzati vengono modificati direttamente, ma nel livello della cache devono essere spostati all'interno e all'esterno della cache man mano che vengono modificati. In un ambiente di clustering la cache è distribuita, pertanto l'ulteriore latenza di rete e la serializzazione dei cavi rallentano ogni singola richiesta effettuata.

La memorizzazione di grandi quantità di dati in una proprietà come infotable è diventata molto costosa e può causare arresti anomali del sistema negli ambienti cluster. Quando viene modificata, ora l'infotable viene completamente letta e scritta nella proprietà. In un ambiente cluster l'oggetto completo viene serializzato, deserializzato e inviato attraverso il cavo. Le infotable di grandi dimensioni devono essere spostate nel database, non memorizzate in una singola proprietà. Possono essere convertite in tabelle definite dall'utente o inserite in una tabella dati.

In un ambiente cluster viene utilizzato Apache Ignite. L'inserimento di oggetti di grandi dimensioni può rendere Ignite non dinamico. Ignite mette in coda le scritture e i backup e, quando vengono inseriti valori di grandi dimensioni, la relativa gestione può richiedere tempo e potrebbe verificarsi il back up dell'elaborazione. Se le dimensioni del backup sono estese, i thread di sistema Ignite iniziano a bloccarsi e questo può comportare la chiusura di un nodo da parte di Ignite, in quanto ritenuto non dinamico. I dati possono diventare sempre più obsoleti.

Per il corretto funzionamento delle applicazioni in un ambiente cluster, potrebbe essere necessario modificarle per ridurre la dimensione dei dati memorizzati nelle proprietà. Questa necessità si verifica in genere in presenza di infotable con migliaia di righe.

Questo esempio era valido prima che venisse aggiunto il livello di memorizzazione nella cache. Aggiornava direttamente la tabella in memoria.

Questa operazione ora deve essere eseguita nel modo descritto di seguito.

Procedura errata:

Ogni riga di questo script estrae l'intera infotable dalla cache, modifica un valore e la inserisce nuovamente nella cache. I round trip nella cache richiedono tempo poiché ogni volta viene elaborata l'intera infotable. Qui vengono eseguite sei chiamate alla cache che, in un sistema remoto, possono rallentare notevolmente lo script.

Procedura corretta:

In questo esempio si ottiene un clone della infotable dalla cache, i dati vengono tutti aggiornati in locale, quindi la infotable viene reinserita nella cache. Le chiamate alla cache vengono ridotte solo a due.

Nell'esempio riportato di seguito viene mostrato come, quando una infotable viene assegnata a una variabile locale, si tratta di un clone. Le modifiche apportate all'oggetto originale non vengono rappresentate nel valore clonato.

Come si può notare di seguito, il clone della infotable è comunque un oggetto proxy. I metodi richiamati per l'oggetto proxy hanno effetto sull'oggetto principale. Il seguente comportamento è coerente con il proxy, ma differisce da quello di ThingWorx 8.4. Se utilizzassimo me.p2 = prop2 in ThingWorx 8.4, verrebbe interrotto il riferimento all'oggetto originale. Ciò non accade in ThingWorx 9, poiché vengono conservati come lo stesso proxy dell'oggetto.

In questo esempio vengono aggiunte righe a una infotable:

Procedura errata:

Sebbene sembri corretta perché utilizza un metodo nel database AddRow, di fatto comporta l'invio al proxy della modifica dell'oggetto originale per ogni iterazione del loop. In questo modo, la infotable viene scritta nella cache per ogni iterazione del loop ed è preferibile evitarlo.

Procedura corretta:

In questo esempio l'oggetto viene clonato in modo da poterlo modificare senza ottenere effetti, se non dopo che è stato assegnato nuovamente all'oggetto originale.

Funziona anche l'esempio che segue. Poiché non si utilizzano i metodi dell'oggetto proxy, l'oggetto originale non viene modificato finché non viene assegnato.