Using DynaMetapushTable with a snapshot loaded from database

garyj

Hi All

I would like to use the DynaMetapushTable to manage live data, however when the 1st user hits the Lightstreamer page, I would like for the table to be built from the database rather than asking the data adapter for the snapshot of the data at any given point in time.

So if the table is prebuilt from the database with say for example 10 rows identified by 1-10 if an update hits Lightsreamer for any of these keys (1-10) then the existing data in the table should be updated.

However if the update hits Lightstreamer with a key being 11 for example (or any other key not already in the table) then a row should be added to the table. As I have no guarantee on the maximum amount of rows due to the nature of the data.

It seems that this functionality is a bit of a cross between the MetapushTable and the DynaMetapushTable, however I would prefer to use the DynaMetapushTable as it's easier to manage row additions.

So am I able to achieve this functionality using the DynaMetapushTable?

Thank you in advance.

Gary

Dario Crivelli

If we understand well, you need to manage a metapush table in which

The initial state of the table is provided by the static contents of the page.
Only the subsequent changes come from Lightstreamer, hence you subscribe to an item in COMMAND mode and don't ask for the snapshot.

This technique is not recommended because of the critical timeframe (between page composition and subscription) in which events can be lost.
Moreover, this technique is partially supported only for MERGE mode and OverwriteTable, but it is not supported for COMMAND mode. Even by using a MetapushTable, which starts with a fixed size, you can only fill the table with placeholders, not with real data. In fact, when the first update event for some key is received from the Server, the table will not look for initial data for the same key, but will just consider that update event as the first data and put it on the first line.
Note that using "showValues" to populate the table is also not feasible, because the support for COMMAND mode is limited to modifying existing rows.

May we investigate on the possibility of taking advantage of snapshot support also in your case?

garyj

The reason I was hoping to avoid using snapshots is because of the added
complexity. Let me explain.

I have a JMS adapter subscribed to a topic similar to the port folio
demo. For any given row in the table the updates are not "very frequent"
i.e. 5 to 10 every half hour. The data feed only lasts for a maximum of
2 hours after which point it is reset and a new feed begins. Hence the
DELETE command cleans the table and a new set is slowly added to the
table as it arrives on the topic using the UPDATE command.

Your assumption in the reply was correct, I wanted to have the initial
state of the table provided "statically" and subsequent changes would
come from Lightstreamer. Each update to the table row modifies the
entire row so there is no concern for any given element in the row as
the whole row is updated every time.

Now if we consider the snapshot approach, when the user loads a
Lightstreamer page the JMS adapter would have to send a request for
snapshots. The system would then need to extract the data from the
database, create a new set of "snapshot" messages and send these
snapshots using the my topic connection.

The way the entire system works is that it received monitoring data from
an external source in UDP datagrams, these are then converted into an
Object graph and written to the database, after which it is passed onto
Lightstreamer for display in real time.

I hope this makes sense....

Thank you again!

garyj

Dario Crivelli

Ok, so in your case the static-snapshot approach is acceptable.

I confirm that, unfortunately, we don't support it on the client side because of a limitation of the DynaMetapushTable. So, what you can do with Lightstreamer is only to get the real-time updates through a NonVisualTable and manage data display by custom code on the "onItemUpdate" event handler.

On the other hand, about extending the Data Adapter to get the snapshot, maybe you can take advantage of the characteristics of your feed. Consider that if you can subscribe to your items (by some dummy client, to be kept permanently attached) before the feed has been attached, then you can always assume that the snapshot is empty and then let Lightstreamer maintain the snapshot for any incoming client.