2012-04-18 8 views
8

Al examinar los registros de eventos en mi Tridion servidor de gestión de contenidos, (estoy usando la versión de 2009) Veo avisos que dicen: prácticas¿Qué prácticas de programación hacen que Tridion informe que una sesión se usa en otro hilo?

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

¿Qué programación/de plantillas son susceptibles de causar esto?

EDIT: Hasta ahora hemos tenido algunas buenas sugerencias:

  1. No guarde el objeto de sesión en una variable estática (Chris)
  2. No guarde el motor o en un paquete de estática variable (Miguel)

De hecho, ambos son de oro macizo, y debería comprobar su propio código para estos antipatrones. (El motor tiene una referencia a una sesión, por lo que tiene sentido.) Aún así, he buscado en la base de código que está causando el problema, y ​​no he encontrado ninguno de estos. Entonces, ¿alguien tiene más ideas? También me gustaría recibir sugerencias sobre cómo depurar este tipo de cosas, o limitar el código problemático.

Respuesta

9

El problema no sólo se producirá cuando el almacenamiento de una sesión, sino también al almacenar cualquier objeto TOM.NET (Component, Page, etc). Cada uno de esos objetos tiene una referencia interna a la sesión que se creó desde cualquier acceso al objeto que puede tener que volver a la sesión para recuperar la información solicitada de Tridion.

Aunque la mayoría de las propiedades que son "nativas" del tipo de elemento parecen recuperarse y mantenerse en una instancia, una llamada como LoadApplicationData puede (tener que) volver a la sesión para acceder a los datos solicitados. Y si esta llamada ocurre en un hilo diferente, recibirás el mensaje de advertencia que mencionas.

He empezado a ver cada objeto TOM.NET que guardo con sospecha y precargar una gran cantidad de datos que pueda necesitar más tarde cuando cargue por primera vez el objeto de su sesión.

+0

Lo he aceptado, ya que creo que realmente aporta nueva información a este problema. Sin embargo, sin faltar el respeto a los otros respondedores. Gracias chicos –

6

He encontrado que si alguna vez almacena el objeto de sesión en una variable estática en una plantilla, se produce este error. Funciona bien en el modo de depuración, pero tan pronto como ejecuto un editor multiproceso (es decir, más de un hilo de representación) este problema plantea su cabeza fea.

+1

vi que esto ocurra en la vista previa en la materia Template Builder. El almacenamiento de sesiones en variables estáticas le generará problemas todo el tiempo, y se supone que este mensaje le advierte sobre esto. –

+0

Esa es una buena respuesta, pero acabo de acertar con el código buscando esto y no lo encontré. Así que todavía estoy buscando otras prácticas que puedan causarlo. –

8

También quiero añadir un comentario basado en experiencias previas. los siguientes escenarios:

  • Sesión y/o del motor y/o paquete se almacenan en variables estáticas
  • Sesión y/o del motor y/o paquete se envían como parámetro a un método que es estático

Puede causar varios problemas aparte de los descritos anteriormente, incluidas las pérdidas de memoria durante la publicación.

Publisher comenzará a consumir memoria hasta que termine en modo no respondedor (No puede detener, ni reiniciar ni deshabilitar) y debe reiniciar el servidor.

Esos problemas pueden ir de mal en peor cuando se hace la publicación masiva

Por lo tanto se recomienda que cualquier cosa que utiliza la sesión, el motor, el paquete debe ser convertido a no estática

A modo de ejemplo, pasar de la siguiente código utilizado para Utilidades initialize se emplean en todos los modelos

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

en

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

puede ahorrar una gran cantidad de problemas

0

Otro escenario es si su sistema de eventos o plantilla o código de flujo de trabajo inicia hilos secundarios y pasa los objetos de sesión o motor a ellos sin los bloqueos adecuados.

En esencia todo lo que cae fuera del modelo de un único subproceso apartamentos, que el motor y los objetos de sesión se basan en: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680112(v=vs.85).aspx

Cuestiones relacionadas