Home/ Questions/Q 7894953
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-03T07:31:29+00:00

When examining the event logs on my Tridion content management server, (I’m using the

  • 0

When examining the event logs on my Tridion content management server, (I’m using the 2009 release) I see warnings that say: 

Session is used on another thread... than it was created on ... 
Session objects are not thread safe.

What programming/templating practices are likely to cause this?

EDIT: So far we’ve had some good suggestions:

  1. Don’t store your session object in a static variable (Chris)
  2. Don’t store your engine or package in a static variable (Miguel)

In fact, both of these are solid gold, and you should be checking your own code for these anti-patterns. (The engine has a reference to a session, so that makes sense.) Still, I’ve searched the code base that’s causing the problem, and I haven’t found any of these. So – has anyone got any more ideas? I’d also welcome suggestions on how to debug this kind of thing, or narrow down on the problematic code.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The problem does not only come about when storing a session, but also when storing any TOM.NET object (Component, Page, etc). Each such object has an internal reference to the Session that it was created from any access to the object may have to go back to the Session to retrieve the requested information from Tridion.

    Although most properties that are ‘native’ to the item type seem to be retrieved and kept on an instance, a call like LoadApplicationData may (have to) reach back to the Session to access the requested data. And if this call then happens on a different thread, you’ll get the warning message you mention.

    I’ve started to look at every TOM.NET object I keep with suspicion and pre-load a lot of data I may need later when I first load the object from its Session.

    • 0