Results 1 to 2 of 2
  1. #1
    Member
    Join Date
    Jun 2008
    Location
    London
    Posts
    2

    recommened usage - multiple item subscription

    Hi All

    My current POC setup is as follows. The idea is to use a group identifier specific to each client. Is this a typical/recommended usage suitable for scaling?
    - One display table which is dynamically generated with unique “row=X” for each price, but same “table=pricing” attribute for all prices.
    - One MetaPush table with a string group identifier that is unique for each web client, eg. group=”price_<sessionId>”
    - On the server side, prices are published to light streamer (via remote adapter) using the unique KEY=”price_<sessionId>”.

    An alternative is to use multiple group identifiers specific to each market (for pricing) and not specific to each client. Is the following setup more efficient/recommended?
    - Multiple MetaPush tables, one for each price. Group identifier is unique for a price, but not unique to each web client (ie. does not include session id). Eg. group=”price_<marketId>”
    - At the server side, prices are published only once to LS (via remote adapter) irrespective of the number of subscribed web clients. Thus presumably, LS server would in turn send a price update to each subscribed (if any) client with a matching key=”price_<marketId>”.

    Or, should I be doing something totally different? Perhaps using a GroupDescriptor/GroupLineDescriptor?

    Many thanks.

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,090
    The question was answered to by direct interaction.

    To resume:

    If the second approach is feasible (i.e. the list of prices can be determined at page initialization and it is not expected to change during the page life),
    then that approach is to be preferred, as it is more efficent.
    Just note that you should setup one OverwriteTable (not MetapushTable) for each price, or a single OverwriteTable which subscribes to all prices in a single group.

    Otherwise, using a single MetapushTable or DynaMetapushTable and a COMMAND mode price-list item for each client, as in the first approach, may be easier.
    The problem is that if a price belongs to multiple price-lists, the Data Adapter must send each update for all the currently subscribed price-list items.

    However, as announced in last July 2008 newsletter, the next minor upgrade of Lightstreamer will provide full "two level push" support, through the new MultiMetapushTables. They would still require price-list items in COMMAND mode, but price details would be acquired through separate price related items (as in the second approach). The page would only need to configure a single MultiMetapushTable (as in the first approach).

 

 

Similar Threads

  1. Replies: 2
    Last Post: December 24th, 2010, 08:51 AM
  2. Multiple Metadata adapter usage
    By stephenlam in forum Client SDKs
    Replies: 5
    Last Post: April 22nd, 2010, 10:19 AM
  3. Replies: 1
    Last Post: November 6th, 2008, 09:44 AM
  4. Multiple rows per item
    By adam.connelly in forum Adapter SDKs
    Replies: 3
    Last Post: August 26th, 2008, 10:42 AM
  5. Replies: 3
    Last Post: August 18th, 2008, 01:55 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 07:25 PM.