Difference between logontoken and serializedsession?

[first_last]

What is the conceptual difference between a logontoken and a serializedsession? Should I prefer one over the other?

ISessionMgr sessionMgr = CrystalEnterprise.GetSessionMgr();
IEnterpriseSession enterpriseSession = sessionMgr.Logon([userName], [password], [cmsName], [authentication]);

// create token
string token = enterpriseSession.LogonTokenMgr.DefaultToken
...
// use token to recreate new EnterpriseSession
IEnterpriseSession enterpriseSession = sessionMgr.LogonWithToken(token);

// create serialized session
string serializedSession = enterpriseSession.SerializedSession;

// use token to recreate new EnterpriseSession
IEnterpriseSession enterpriseSession = sessionMgr.getSession(serializedSession);

Does the LogonWithToken method hit the repository where the getSession method does not? Is one smaller (fewer bytes) than the other? Is one faster?

PS: is there a way to mark code inline, rather than using italics as I've done?

[DellSC]

When you log on with a token, you can set the number of logons and the amount of time a token a valid for. A serialized session is just a serialized version of the session - it is only good for the current logon and for the default amount of inactive time.

I have used tokens in a number of situations, most recently with a web site that had a micro services back end. Within the application, a user could access multiple reports during a session. For each report, there could potentially be multiple service calls - for example, one to get the parameters that are valid in the report, and another to get the full OpenDocument URL for the report, including the user selected parameter values. The token gets passed back to the service with every call and with many of the calls, the user is logged off just before the info is sent back to the GUI. This helps prevent memory issues in the back end because it doesn't have various serialized sessions sitting around in its processes. With the token, I can log the user back in with the same token without having to get another session. This way the token is tracked and stored in the front end as well.

-Dell

[first_last]

I've used the token for similar usage-cases.

But I started to wonder if a serialized session might be more efficient. Can the .Net client assembly create the EnterpriseSession instance w/o a trip to the server? Does the LogonWithToken require a trip to the server? Which is faster? I'll trade a little more memory usage in my web or powershell app for faster transactions.

Also, it's great having a discussion w/ someone with similar experiences. +1

[DellSC]

Thinking about this a little more, one of the reasons I use the token is because the code for logging in is in the back-end, but the token is stored in the front end. In this case, if you create a new session for the next user, how do you know whether it has overwritten the one that was created by the SessionManager for the previous user? Because the back end is not in the context as the front end when the back end is a service, I think you might have issues with the session timing out. Of course, I may be wrong - I mostly write back end utilities where this is not an issue and I sometimes have a hard time grokking the flow of what's valid where in a web application.

-Dell