rsouissi
Hi,
Is there any noticeable performance gain if the the data adapter uses SmartDataProvider interface instead of the normal DataProvider ?
The documentation says it could be faster because the adapter uses a handle of the subscribed item instead of a string keyword.
Regards
A
Dario Crivelli
Hi
Yes, the "smartUpdate" implementation is faster than the "update" implementation, thanks to the received handler (which can be seen as an item-related listener).
If the Data Adapter implementation is already based on item-related internal listeners, the Data Adapter can easily implement the handler support.
If, on the other hand, implementing the handler support would mean complicating the Data Adapter code and adding new Map lookups, then the overall performances might be unchanged.
We can't really say that the performance impact would be "noticeable".
Consider that the "update" implementation is the only place in the Kernel where a lock on a global object is taken for every single update.
If the Data Adapter uses multiple threads to issue the various "update" calls, this may be undesirable.
Dario
juls
Hi
I’m new to Lightstreamer and have been experimenting with the Adapter Remoting Infrastructure Spec using Java over TCP Sockets.
I was hoping that someone could explain in more detail the value of the itemHandle Object in the SmartDataProvider.
I understand that this is normally provided by the Lightstreamer Kernel but in order to replicate this logic in a remote data provider server I would like to find out more about it. I modified the sample HelloworldDataAdapter to log the value of the itemHandle but I only get the memory address of some obfuscated Lightstreamer object (com.lightstreamer.i.p@61a907).
I noticed in the javadoc for the SmartDataProvider interface that Lightstreamer always supplies different handles across subsequent subscriptions of the same item, could this be as simple as using an incremented Integer?
If anyone could provide some insight into what this object is/should be it would be most appreciated.
Thanks
Dario Crivelli
The handle distinguishes each different instance of the "subscribe" call, so that you can always associate a "smartUpdate" call you issue with the originating "subscribe" instance (hence, the item).
Supplying a specific listener object, with its own "smartUpdate" interface, instead of the handle, would have been more compliant with an object oriented interface, but we just couldn't at the moment we introduced it (actually, the handle is the pointer to the internal listener).
In ARI terms, the <ID> element of the subscription request message plays the same role as the handle, in that it has to be specified on each update message related with the subscription request.
