I have an App that connects with Salesforce and do different operations. So I'm trying to implement a Session Cache for the Application to avoid repetitive login calls.

So far what I have done is I have created a ConcurrentHashMap which stores a Session Object (object consists of SessionID, CreatedTime, Validity, ServiceURL etc.) When a new request comes in I get the Session object from the HashMap, check the validity of the session and if valid return the session.

Recently I learned that Salesforce session is like a user Session, as long as you do requests with the Same sessionID it's kept active, if you idle for X amount of time it expires. So I'm thinking of the best way to implement this.

Initially I thought of adding a new field like lastAccessTime to the Session object and validate based on this. But the problem is since my App is a highly concurrent application which handles many requests, each time a request comes-in I will be retrieving the session updating lastAccessTime and adding back to the HashMap, which feels like a overhead.

Is there any better way to do this (I was thinking may be maintain two HashMaps, one for the Session Object, one for the lastAccessTime)? Or can I simply ignore the fact that session is updated on access and stick to the initial session generated. Probably I would do more requests to Salesforce but between updating the session Map on each request I would feel that's more efficient.

  • So question: your application is a web application and you are managing SalesForce sessions on behalf of your users? Or is your application a desktop or phone app that only needs to cache values for one user? It sounds like the former but want to be sure. Nov 16, 2022 at 2:30
  • @BerinLoritsch It's neither. The user session is not associated with the Salesforce session in my case. My App is something like a ESB. It received a HTTP requests and based on that request the App will perform some Salesforce operation and for this we have a dedicated Salesforce user which is used by the App. Based on the operations we do within the App we maintain different user accounts to connect to Salesforce. But max number of different user accounts will be < 5. Previously per each operation call we did a Login call to Salesforce, this is what I'm trying to optimize.
    – Arun Lal
    Nov 16, 2022 at 3:18

1 Answer 1


and adding back to the HashMap

Why? Activity isn’t a reason to remove from the map. Timing out is.

Before worrying too much about this create a good test that shows if this really is a bottleneck.

You could simply store lastAccessTime in the session object and let the object update and report on that itself. I’m hesitant about that because it makes the session object mutable and you said this was highly concurrent.

A concurrency tolerant solution might be to simply build new maps on cleanup. Say your sessions expire after 15 minutes. Maintain 5 maps. On activity add the session to all 5. After 3 minutes dump the first map and start a new one. You’re still maintaining 5 maps and the only mutation is to which maps hold current sessions.

If you’ve thinking that’s 5 times the work you haven’t studied big O notation. If that’s too much you're likely solving a non-problem.

Since you’re trying to optimize multiple activity in quick succession start the check with the newest map.

The big saving here is you don’t hold dead sessions. So they aren’t eating memory or bloating the maps. You don’t have to loop the map to get rid of them. Just toss the whole map.

The sacrifice is to the granularity of the timeout. Do you care about timeouts being accurate to the millisecond?

This simplifies what you’re doing with the map. The map should only store a reference to the session object. It should not have any idea that sessions timeout. Sessions are in the map or they aren’t.

Disclaimer: I’ve never coded this nor seen code that does this. Just an idea that popped into my head. If you try this, TEST.

  • Thanks for the answer. I really don't have a concern of memory growth, as I just have less than 5 different users, so in total I will have 5 entries in the Map. ATM sessionCleanup is done when validating the session, if the session is invalid the entry is removed from the HashMap and returned Null. But as you mentioned I would say around 5 threads would simultaneously update the Session object mutating it, if I store the lastAccessTime in the session object. So my first question is, will it cause any issues? I really don't want to Synchronize the methods which will block the Threads.
    – Arun Lal
    Nov 16, 2022 at 5:12
  • The second question is, in the solution you proposed how would having Multiple Maps resolve the Mutation problem? I would assume you will find the same session in the latest Map and will keep on updating it.
    – Arun Lal
    Nov 16, 2022 at 5:13
  • @ArunLal the multiple map solution allows session to be immutable. Adding a session reference to map is atomic. Updating the fixed length queue of maps can be managed on a single thread. Doing it that way I don't see much need to synchronize. A wild thread updating a dead map doesn't hurt anything. Nov 16, 2022 at 5:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.