What programming methods cause Tridion to report that the session is being used in another thread?

When viewing event logs on my Tridion content management server (I am using the 2009 edition), I see warnings that say:

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

What programming / template methods can cause this?

EDIT: So far, we have had some good suggestions:

  • Do not store your session object in a static variable (Chris)
  • Do not store your engine or package in a static variable (Miguel)

In fact, both of them are solid gold, and you should check your own code for these anti-patterns. (The engine has a link to the session, so that makes sense.) However, I was looking for a code base that was causing the problem, and I did not find any of them. So - does anyone have any ideas? I also welcome suggestions on how to debug such things or narrow down problematic code.

+8
tridion
source share
4 answers

The problem arises not only when storing a session, but also when storing any TOM.NET object ( Component , Page , etc.). Each such object has an internal link to the session that was created from any access to the object, you may need to return to the session to get the requested information from Tridion.

Although most properties that are "native" to the element type seem to be retrieved and stored in the instance, a call, such as LoadApplicationData , may (should) return to the session to access the requested data. And if this call occurs in another thread, you will receive the warning message that you mentioned.

I started looking at every TOM.NET object that I suspiciously hold and preload a lot of data that may be needed later when I first load the object from its session.

+9
source share

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 packet are sent as a parameter to the Static method

There may be several problems besides those described earlier, including memory leaks during publication.

The publisher will start consuming memory to the end in non-responsive mode (you cannot stop, restart, or shut down), and you need to restart the server.

These problems can go from bad to worse by mass publishing.

Therefore, it is recommended that everything that uses the session, engine, package package should be converted to non-static

As an example, let's move on to the following code used to initialize the Utilities used in all 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; } } } 

in

 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; } } } 

You can save a lot of problems.

+8
source share

I found that if you ever store a session object in a static variable in a template, this error occurs. It works fine in debug mode, but as soon as I launch a multi-threaded publisher (i.e. More than one rendering stream), this question raises an ugly head.

+6
source share

Another scenario is that your event code or template or workflow code starts child threads and passes Session or Engine objects to them without the corresponding locks.

Essentially everything that goes beyond the Single-Threaded Apartments model, in which the Engine and Session objects are based on: http://msdn.microsoft.com/an-us/library/windows/workspace/ms 680112 (v = vs .85) .aspx

0
source share

All Articles