LS_Developer
Just want to understand if the connection mode is changed due to networking environment change, from streaming to pulling or pulling back to streaming, will the session id remain the same?
Thanks
Dario Crivelli
I can't understand the exact case you are referring to (and I suppose that by "pulling" you mean "polling"), but, as a general answer:
there are no cases in which the .NET Client Library switches a session between polling and streaming.
Only in the Stream-sense phase, a session opened in streaming may be replaced by a session opened in polling, but the application is not even aware of the former, temporary, session: it is only visible in the Server log.
LS_Developer
I should post this question under .net data adapter development. The reason for asking this question is because the data adapter I developed is using session id of LS to push user specific data to client side. If the session id can be changed throughout the life span of the connection, it will mess up the user states in the data adapter. What is the best practice to keep track of user state on the data adapter?
Dario Crivelli
During the life of a client application it is always possible that multiple sessions are opened, each of which with a different ID; in fact, the client could disconnect and reconnect, or recover from an interruption due to network problems.
In general, these sessions don't overlap and the Metadata Adapter can rebuild the user history by sensing the NotifyNewSession and NotifySessionClose calls.
In some cases, like in the Stream-sense case, two sessions may even overlap.
If overlapping is a problem, then your Metadata Adapter has the option of forcing the existence of one single session by throwing a ConflictingSessionException from NotifyNewSession when needed.
We are working on a way to simplify the interface with the Metadata Adapter on this respect, but no results are expected for the forthcoming release.
However, for instance, the Html Client Library, since version 5.0, no longer changes the session because of the Stream-sense or when resorting to polling if the client can't keep up with a huge streaming update flow.
We may try to help you, if you provide us with more details on your case.