I can try to find out notes on why userid change was a no no. Or at least a HUGE impact on perf since you basically have to stand up a new Operation (e.g. Server Call). But in general, you need to make another server call so didn’t bother in the few scenarios we had - just use the alternate credentials from the client.
A Temp session lasts the life of the server call or shorter - ideally the span on what inside a for loop as you iterate different companies, plants, etc.
foreach(var company in companyList)
{
using (CallContext.TemporarySessionCreator.SetCompanyID(company).Create())
{
DoSomething(company);
}
}
Calling Session.SetCompany changes the default Company forever - or until the users clicks on a new Company, etc. If you think about ‘sagas’ in the transaction world you’ll get a hint of what I mean. Session is the breadcrumb trail of all those little context settings about current company, plant, site, workstation, currency, language, etc etc.
Temp does a ‘temporary’ hijacking of that saga to make a quick change in context of something else. Think Admin cleanup type functions where you are iterating over all the companies in a group.