What programming practices cause Tridion to report that a session is used on another thread?

Question

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.

Answer 1

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.

Answer 2

I also want to add a comment based on previous experiences. The following scenarios:

• Session and/or engine and/or package are stored in Static Variables
• Session and/or engine and/or package are sent as parameter to a method that is Static

Can cause several issues apart of the described previously, including memory leaks during publishing.

Publisher will start consuming memory till end up in non responding mode (You can't stop, nor restart nor disable) and you need to reboot the server.

Those issues can go from bad to worse when doing massive publishing

So is recommended that anything that uses session, engine, package should be converted to non static

As an example, moving from the following code used for initialize Utilities used across all the templates

using System;
using System.Collections.Generic;
using System.Text;
using System.Text.RegularExpressions;
using System.Xml;
using Tridion;
using Tridion.ContentManager;
using Tridion.ContentManager.CommunicationManagement;
using Tridion.ContentManager.ContentManagement;
using Tridion.ContentManager.ContentManagement.Fields;
using Tridion.ContentManager.Templating;
using Tridion.ContentManager.Publishing;


namespace sample.sample1
{
    public class Utilities
    {
        private static Engine  _engine;
        private static Package _package;

        public void InitializeUtilities(Engine e, Package p)
        {
            _engine = e;
            _package = p;
        }
    }
}

into

using System;
using System.Collections.Generic;
using System.Text;
using System.Text.RegularExpressions;
using System.Xml;
using Tridion;
using Tridion.ContentManager;
using Tridion.ContentManager.CommunicationManagement;
using Tridion.ContentManager.ContentManagement;
using Tridion.ContentManager.ContentManagement.Fields;
using Tridion.ContentManager.Templating;
using Tridion.ContentManager.Publishing;


namespace sample.sample1
{
    public class Utilities
    {
        private Engine _engine;
        private Package _package;

        public void InitializeUtilities(Engine e, Package p)
        {
            _engine = e;
            _package = p;
        }
    }
}

Can save a lot of issues

Answer 3

I have found that if you ever store the session object in a static variable in a template this error occurs. It works fine in debug mode, but as soon as I run a multi-threaded Publisher (i.e. more than one rendering thread) this issue raises it's ugly head.