Controlar el bloqueo de llamadas

Para mejorar la escalabilidad de las aplicaciones, Visual FoxPro dispone de objetos SingleUse y del subproceso del modelo Apartamento como medios para controlar el problema del bloqueo de llamadas.

Objetos SingleUse

Al asignar el valor SingleUse a la propiedad Instancing de una clase OLEPUBLIC en el cuadro de diálogo Información del proyecto, cada instancia de la clase se ejecuta en una instancia diferente de su componente. Esto significa que, aunque su componente sea de un solo subproceso, cada instancia de la clase SingleUse tiene su propio subproceso de ejecución. El comportamiento de los objetos SingleUse es diferente en los servidores .exe y .dll:

Objetos SingleUse en servidores EXE

Cuando el valor de la propiedad Instancing es SingleUse, cada instancia hace que comience un proceso EXE nuevo (en Windows NT 4.0 o superior verá cada proceso en ejecución en el Administrador de tareas). Cuando el valor es MultiUse, la primera instancia hará que comience un nuevo proceso, pero cada instancia nueva del objeto comparte el mismo proceso que la primera.

Objetos SingleUse en servidores DLL

La propiedad Instancing se omite para las .dll de varios subprocesos y es de sólo lectura para el tiempo de ejecución Vfp7r.dll. Los servidores generados para su uso con la biblioteca vfp7t.dll siempre son MultiUse, independientemente de su configuración. En general, debe establecer siempre la propiedad Instancing en MultiUse para los servidores en proceso de vfp7r.dll. Si la establece en SingleUse, sólo se puede crear una instancia de un objeto desde ese servidor. Si intenta crear instancias de otros objetos, se producirá un error. Sólo en raras ocasiones tendrá que utilizar el valor SingleUse. De hecho, los componentes de Microsoft Transaction Server requieren el valor MultiUse. Con frecuencia, los objetos SingleUse requieren más memoria que varios objetos de un componente con varios subprocesos.

No obstante, existen algunas razones por las que podría tener que utilizar objetos SingleUse. Por ejemplo, puede utilizar objetos SingleUse para aislar actividades de alto riesgo en procesos diferentes. Si se produce un error grave en el objeto, los demás procesos no resultan afectados. Por el contrario, un error grave en un componente de varios subprocesos termina todos los subprocesos.

Subproceso del modelo Apartamento

Ahora, los servidores de automatización de Visual FoxPro son compatibles con el subproceso del modelo Apartamento. Microsoft Transaction Server utiliza los servidores marcados como de subproceso del modelo Apartamento y ofrece mejor protección y escalabilidad de los subprocesos mediante la serialización y el cálculo de referencias.

En Visual FoxPro, el subproceso del modelo Apartamento proporciona seguridad a los subprocesos. En el subproceso del modelo Apartamento, cada subproceso es como un apartamento; es decir, todos los objetos creados en un subproceso viven en ese apartamento y no conocen los objetos de los demás apartamentos. En cada objeto del modelo Apartamento (por ejemplo, un servidor de automatización de Visual FoxPro) sólo puede entrar un subproceso: el subproceso que creó el objeto. Sin embargo, un servidor de objetos, como Microsoft Transaction Server, puede admitir múltiples objetos, en cada uno de los cuales pueden entrar simultáneamente subprocesos diferentes. Los datos comunes que mantiene el servidor de objetos se deben proteger contra colisiones entre subprocesos.

El subproceso del modelo Apartamento ofrece las siguientes ventajas:

• Todos los objetos que un cliente crea en un subproceso determinado se crean en el mismo apartamento (subproceso) de la DLL. Las llamadas a esos objetos realizadas en el mismo subproceso no requieren el cálculo de referencias entre subprocesos, lo que las hace más eficaces.
• Debido a que el acceso a un objeto sólo se realiza en el subproceso donde se creó, las llamadas se serializan, de manera que una llamada nunca es interrumpida por una llamada de otro subproceso.
• Se realizan cálculos de referencias de los argumentos de las llamadas entre procesos y el subproceso que llama se bloquea. Esta sincronización de los datos protege el estado del subproceso que llama.

Las DLL de subproceso del modelo Apartamento no pueden crear sus propios subprocesos; la primera vez que un subproceso cliente pide un objeto que proporciona la DLL, se crea un nuevo apartamento y se ejecuta el evento Init del objeto para ese apartamento. Todos los objetos clientes de un solo subproceso que pida ese cliente residirán en el mismo apartamento y compartirán los datos globales. Los objetos PRIVATE (incluidos los formularios) creados por los objetos públicos también residirán en el apartamento.

Como en Visual FoxPro no hay manera de que un apartamento tenga acceso a otro, un cliente con varios subprocesos podría obtener una referencia a un objeto en el subproceso A y pasar esa referencia a un objeto del subproceso B.

Para obtener más información acerca del subproceso del modelo Apartamento, consulte el apartado relativo a dicho tema en la Biblioteca MSDN.

La implementación en Visual FoxPro del subproceso del modelo Apartamento elimina los conflictos de acceso a los datos globales desde varios subprocesos, ya que se asigna a cada apartamento su propia copia de los datos globales. Esto significa que todos los objetos creados en el subproceso existen en ese apartamento y que no conocen los objetos de los demás apartamentos.

Visual FoxPro utiliza un almacén local de subprocesos para almacenar un conjunto exclusivo de datos globales del entorno y de la aplicación para cada subproceso (apartamento). Esto significa que dos instancias de la misma clase creadas en dos subprocesos diferentes no tienen acceso a los datos entre sí. No obstante, si estas dos instancias residen en el mismo subproceso, cada objeto tiene acceso a los datos del otro. Esto podría causar problemas de temporización en sus aplicaciones. Siempre que dos objetos del mismo subproceso se crean a partir de clases OLEPUBLIC en el mismo servidor .dll, los datos de esos objetos son comunes a ambos. (Nota: puede utilizar la clase Session para dar a cada objeto una sesión de datos privada exclusiva.)

Además del almacén local de subprocesos, Visual FoxPro también proporciona a cada proyecto (.dll) un conjunto único de datos globales. Los objetos que se crean a partir de diferentes proyectos (servidores .dll) no tienen acceso a los datos globales de los otros, aunque los dos objetos residan en el mismo subproceso.

Vea también

Seleccionar tipos de proceso | Seleccionar una biblioteca de tiempo de ejecución | Interoperabilidad e Internet | Lenguajes admitidos en tiempos de ejecución | Notas sobre la programación de servidores de automatización