Updating In-Memory Tables

TIBCO Patterns supports addition, lookup, updating, and deletion of records in existing in-memory tables. Like the initial loading of records into a new table, record additions might flow to the server over a socket connection from a remote source or a server-side local file. Updates of the existing records can only be performed over a socket connection and updates direct from a server-side file are not supported.

Any operation that modifies a table causes all other operations that would either read or modify that table to be blocked (table-level locking). Such operations are queued and automatically unblocked when the table-modifying command is completed.

Applications that do not require continual data updates might find it simpler to replace an entire table with a new version according to an appropriate schedule. This is easily accomplished by loading the new version of the table under an alternate name. While this load is progressing, queries remain enabled on the previous version. When the load of the new version is completed, it can be renamed from the alternate name to the standard name of the table. This effectively replaces the previous version of the table with the new version without appreciable down time.

Considerations

It requires enough memory to hold two copies of the table in memory at the same time. Therefore, it is a good option for small to mid-sized tables that are updated by the way of a periodic batch run.

This method cannot be used to update a joined set of tables. For more information about joined tables, see Joins.

This method of swapping tables can also cause memory growth due to fragmentation of memory. Although it is not a memory leak, fragmentation can result in a process accumulating large amounts of unusable memory. Frequently reloading and swapping tables might lead to excessive memory usage due to fragmentation, which might require periodically restarting the TIBCO Patterns server.