Manejando Ciclos de Vida de Componentes Easerver PDF

Ciclo de Vida de los Componentes | 1
Capítulo 5
El ciclo de vida del Componente EAServer
En este capítulo vamos a tratar acerca del ciclo de vida de los componentes, como se deben
diseñar y cuales son las ventajas y desventajas.
Contenido:
• Alcance general del ciclo de vida del Componente EAServer

• Componentes stateful y stateless
• El instance pooling
_____________________________________________________________________________________________
Derechos Reservados de TechEra e-Learning
Este producto solo puede ser usado para uso personal y no para otros fines.
Manejando el comportamiento de los componentes
PowerBuilder provee un ideal ambiente de desarrollo para construir los componentes

EAServer. Antes de tomar ventajas del desarrollo en PowerBuilder, es importante primero
comprender como el servidor Jaguar maneja los componentes y las instancias de los
componentes cuando son requeridos.
Los Componentes EAServer
EAServer controla todos los componentes usando las propiedades especificadas para el
componente en el Repositorio de EAServer. El ciclo de vida de una instancia de un
componente EAServer es manejado independientemente del lenguaje o modelo de
componente en el cual fue escrito. El ciclo de vida del componente EAServer determina
cuando y como las instancias son creadas, llamados por los clientes y destruidas.
El ciclo de vida (life-cycle) del componente EAServer
Un componente EAServer puede tener uno de estos estados en el servidor Jaguar, tal como
se muestra en la figura 5.1.
Figura 5.1
El ciclo de vida del componente EAServer
Eventos del ciclo de vida de componentes EAServer
Un componente puede implementar los eventos del ciclo de vida de EAServer, a

continuación se detallan estos eventos:
• Constructor
• Activate
• Deactivate
• CanBePooled
• Destructor
Constructor
El evento Constructor es invocado cuando el componente es inicialmente creado (primer

método llamado), este evento es estándar para cualquier custom class user object (CCUO).
Activate
El evento Activate es invocado cuando el componente es ligado al cliente y es usado para

inicializar los valores de las variables de instancias.
_____________________________________________________________________________________________
Deactivate
El evento Deactivate es invocado cuando el componente es desligado del cliente y es usado

para liberar recursos.
CanBePooled
El evento CanBePooled es invocado justo después del evento Deactivate es invocado para
determinar si la instancia puede ser reusada, si se indica el valor de retorno 1 es reusado, el
valor por defecto es 0 que no permite ser reusado al objeto, este Evento solo será activado
cuando la opción instance pooling es desactivada.
Destructor
El evento Destructor es invocado cuando el componente es destruido, este evento es

estándar para cualquier custom class user object (CCUO).
NOTA: Cuando se crea un componente EAServer con el Wizard, te genera los eventos
Constructor, Destructor, Activate y Deactivate, el evento CanBePooled debe ser adicionado
manualmente (con el event ID pbm_component_canbepooled)
Figura 5.2
Eventos del Ciclo de Vida
Diseñando los componentes
Los componentes pueden ser diseñados como:
Stateful
Stateless
Componente Stateful
Los componentes stateful guardan información en las variables de instancia entre llamadas
de métodos. La instancia del componente no es desactivado entre llamadas de métodos y
permanece ligado a una sesión cliente. La mayoría de lectores tendrán una experiencia
construyendo este tipo de componentes, desde que estos objetos fueron desarrollados para
aplicaciones cliente/servidor y Distributed PowerBuilder son por defecto stateful. Los
componentes stateful son fáciles de implementar porque ellos guardan valores entre
llamadas de métodos, permitiendo a la información ser acumulada por muchas llamadas a
métodos. Usando este tipo de componentes no ayuda al servidor a estar libre porque los
recursos del servidor son sostenidos por las conexiones cliente, aunque ellos no estén en
uso. Una conexión cliente puede invocar dos o más llamadas a métodos de una instancia de
componente, pero puede permitir una cantidad significante de tiempo entre llamadas de
_____________________________________________________________________________________________
métodos. El tiempo entre llamadas de métodos no maximiza el uso de recursos del servidor
si la instancia del componente no está en uso pero permanecerá activo y ligado a una sesión
cliente. Esto amarra los recursos del servidor y deja con la opción para un Memory leak del
EAServer.
Los componentes Stateful deben de ser desactivados por la aplicación llamando a métodos
que invoquen a los transaction primitive. También es importante señalar que el componente
stateful pierde el estado y es desactivado cuando una transacción implícita manejada por el
servidor Jaguar ha sido completada. Debido a esto, puede ser necesario desarrollar objetos
que soporten transacciones como los stateless.
Configurando un componente para ser stateful
El solo requerir configurar para crear un componente stateful requiere deshabilitar la

propiedad Automatic demarcation/deactivation. Hay, sin embargo, recomendaciones de
configuraciones de los objetos stateful para mantener los estados entre llamadas de los
métodos y transacciones :
• Poner la propiedad Automatic demarcation/deactivation desactivada

• Poner la propiedad de transaction en Not supported
• Crear un método of_deactivate para permitir al cliente desactivar el componente.
• Poner la propiedad del instance timeout en cero
Las dos últimas recomendaciones permiten al componente stateful ser desactivado y así
reducir la posibilidad del Memory leak del EAServer.
Un ejemplo de un componente stateful
En esta sección vamos a trabajar con un componente stateful muy simple que permite al
usuario ingresar valores y asignarlos con una llamada a un método, y recuperar el valor con
una segunda llamada a otro método.
Debemos primero abrir el workspace techera5.pbw que se encuentra en el directorio

c:\techera\capitulo5, este workspace contiene dos targets: operaciones_servidor.pbt y
operaciones.pbt, una vez abierto este workspace debemos de verificar el objeto
n_operaciones_ciclo en el target operaciones_servidor.pbt, y debemos de revisar el objeto
project p_operaciones_servidor, en la opción de propiedades en el tab “Components”
debemos de desactivar la opción “Automatic demarcation/deactivation” y la opción “Support
instance pooling” (figura 5.3).
Figura 5.3
Propiedades del objeto project p_operaciones_ciclo
_____________________________________________________________________________________________
Debemos de abrir el objeto n_operaciones_ciclo, y debemos de verificar que las variables de

instancias que se indican abajo, figuren en la opción Declare Instance.
Protected:
integer ii_valor1
integer ii_valor2
ErrorLogging iel_jag
TransactionServer its_jag
Nota: El objeto ErrorLogging provee habilidad para escribir mensajes al archivo log usado,
como el archivo log del servidor Jaguar para el EAServer o el archivo log del sistema
Operativo, este objeto tiene una función llamada log().
El componente n_operaciones_ciclo debe tener tres funciones: of_valores, of_calculo, y

of_desactivar. La función of_desactivar debe ser usado para desactivar la instancia del
componente.
La función of_valores permite a la aplicación cliente pasar los valores al componente y

almacenarla en las variables de instancia. El código para esta función es listado abajo :
//of_valores
//argument : long al_valor1
long al_valor2
il_valor1 = as_valor1
il_valor2 = as_valor2
RETURN 1
La función of_calculo permite a la aplicación cliente recuperar los valores del componente. El
código para esta función es mostrada abajo :
// of_calculo
//argumento : (reference) string as_operador
long ll_resultado
CHOOSE Case as_operador

Case ‘+’
Il_resultado = ii_valor1 + ii_valor2
Case ‘-’
_____________________________________________________________________________________________
Il_resultado = ii_valor1 - ii_valor2

Case ‘*’
Il_resultado = ii_valor1 * ii_valor2
Case ‘/’
Il_resultado = ii_valor1 / ii_valor2
END CHOOSE
RETURN Il_resultado
Una vez revisado las funciones del objeto n_operaciones_ciclo, debemos de realizar el
deploy en el objeto project para desplegar el componente al servidor Jaguar (el proceso de
deploy se indicó en el capítulo 4).
Nota: El servidor que viene configurado con el objeto project está direccionado al servidor
“techera”, el lector tendrá que cambiarlo por el nombre de su máquina, esto se realiza en las
propiedades del objeto project p_operaciones_servidor en el tab “EAServer Host”.
Ahora vamos a necesitar una aplicación cliente para probar el componente, vamos a usar la
ventana w_operaciones del target operaciones.pbt, tal como se muestra en la figura 5.4.(esta
ventana es proveída por el autor).
Figura 5.4
Interfaz de la aplicación cliente
Este ejemplo es casi igual al que creamos en el capítulo 4, y lo vamos a utilizar para poder
probar los componentes stateful, en esta sección lo único que vamos a cambiar es la
invocación de los datos en el botón Valores, el cual se encargará de invocar al método
of_valores, y luego presionaremos el botón Procesar que se encargará de realizar el proceso
en el servidor.
Ejecutando el ejemplo
Antes de ejecutar la aplicación cliente, inicializar el Jaguar Manager y abrir el Runtime

Monitor para el componente n_operaciones_ciclo (El Runtime Monitor se encuentra dentro
del servidor Jaguar, esto se activa haciendo click y luego buscar el componente en el fólder
Packages dentro de operaciones). Una vez que el Runtime Monitor es activado, ahora
debemos de revisr el objeto Connection “n_connect” y en la función of_getconnectioninfo()
debemos verificar que está apuntando a nuestro servidor (en el caso del lector será el
nombre de su máquina o servidor EAServer, sino realiza esto recibirá un mensaje de que no
se pudo conectar al servidor), luego ejecutar la aplicación, ingresar los valores a los campos,
luego presionar el botón de Conectarse y el de Valores, cuando este botón es presionado, el
primer método en el componente n_operaciones_ciclo es llamado. Esto crea la instancia del
componente y enlaza a la sesión cliente. Los valores son pasados a la función y estos
valores son almacenados en las variables de instancia en el componente. La figura 5.5
_____________________________________________________________________________________________
muestra la llamada a la función of_valores y también muestra al componente como está

activo y ligado a una sesión cliente.
Figura 5.5
El Runtime monitor después de presionar el botón Valores
Note que el componente permanece activo incluso después de que el método completó el
proceso. Esto es indicado por que el valor del Instances Active permanece fijo en uno(1.0). la
figura 5.6 ilustra como se ve el servidor Jaguar donde el componente n_operaciones_ciclo es
ligado a una sesión cliente. Desde que el componente es stateful, esto permanece ligado a
una sesión cliente y la información que es almacenada en las variables de instancia ii_valor1
y ii_valor2 guardan estos valores.
Figura 5.6
Un componente stateful en el servidor Jaguar
Cuando el botón Procesar es presionado, la función of_calculo es llamado y el valor del

Method Invocations es incrementado (vea la figura 5.7). los valores que fueron almacenados
en las variables de instancia en la llamada de la función of_valores son retornados. Los
valores de las variables de instancia están disponibles porque el componente es stateful y ha
permanecido activo y asignado a una sesión cliente entre las dos llamadas de los métodos.
Figura 5.7
El Runtime monitor después de presionar el botón Procesar
_____________________________________________________________________________________________
Note otra vez que el componente permanece activo después de que el método
completó el proceso como es indicado por el valor del Instances Active que
permanece en uno (1.0). Luego presione el botón Desactivar para desactivar la
instancia del componente esto hace la llamada a la función of_desactivar porque el
instance pooling no es soportado. El Runtime Monitor confirma esto indicando que la
instancia no está activa por un largo tiempo y no es pooled (vea la figura 5.8).
Figura 5.8
El Runtime monitor después de cerrar el window
La figura 5.9 muestra que está pasando en el kernel del servidor Jaguar después de
que el componente es desactivado y destruido.
Figura 5.9
Desactivación de un componente stateful
_____________________________________________________________________________________________
Componentes Stateless
Un componente que es desactivado después de cada llamada a un método es stateless. La

información entre las llamadas de los métodos no es mantenida por el componente. Si debe
conservarse la información entre las llamadas de los métodos, la información debe ser
pasada a través de los métodos o el componente necesita reinicializar el estado cargando los
valores anteriores en las variables. Valores que son sostenidos entre llamada de métodos
deben guardarse en un cache persistente. Ejemplos de cache persistente incluyen objetos
shared, una base de datos, y un archivo. Los componentes stateless son recomendados para
ayudar a la performance del servidor para reducir el consumo de los recursos del servidor.
Cuando los componentes stateless son usados junto con el instance pooling, una instancia
de un componente puede ser reusado por muchas sesiones de clientes. Esto permite
maximizar los recursos del servidor, desde que las instancias de los componentes idle no son
sostenidas por las sesiones clientes. esto incrementa la escalabilidad del servidor Jaguar.
Configurando un componente para ser stateless
La única configuración necesaria para crear un componente stateless es habilitar la

propiedad Automatic demarcaction/deactivation del objeto project p_operaciones_servidor.
Cuando esta propiedad es habilitada, el componente es automáticamente desactivado
después de cada llamada a un método.
Un componente PowerBuilder puede ser stateless habilitando la opción Automatic

demarcation/deactivation en el objeto project, antes de hacer deploy (vea la figura
5.10).
Figura 5.10
El proyecto del componente EAServer
Nota: Para acceder a esta opción, debemos primero estar en el painter del objeto project y
luego presionar el icono Properties del toolbar de PowerBuilder.
Otra forma para poner un componente EAServer como stateless, es abrir el Jaguar Manager
y encontrar el componente dentro del package en el cual fue instalado. Abrir la ventana de
diálogo de las propiedades del componente para resaltar el nombre del componente y
presionar el botón derecho del mouse (vea la figura 5.11). seleccionar la opción de
Component Properties del menú popup y presionar el tab Transactions ilustrado en la figura
5.11. activar la opción Automatic demarcation/deactivation y presionar Aceptar para grabar.
Para asegurarse que esta opción toma efecto, encontrar el nombre del servidor dentro del
_____________________________________________________________________________________________
fólder Servers en el Jaguar Manager y refrescar el servidor, para seleccionar refrescar en el

menú popup, presione el botón derecho en el nombre.
Figura 5.11
Poniendo un componente como stateless
Un componente EAServer también puede ser implementado como un componente

stateless para llamar a cada transaction primitive SetComplete o SetAbort al final de
cada función. Esto fuerza al desarrollador, sin embargo, recordar codificar una de
estas llamadas de funciones al final de cada función. Implementando un componente
stateless sin usar la opción Automatic demarcation/deactivation también hace esto
difícil para determinar si un componente es stateless o no en el Jaguar Manager.
Haciendo los componentes stateless
Ahora debemos de ejecutar el último ejemplo usando un componente stateless. Poner el

componente EAServer n_operaciones_ciclo, para ejecutarse como un componente stateless
(activar la opción Automatic demarcation/deactivation en el objeto project). Ahora ejecute el
ejemplo.
Lo primero es ingresar los valores a los campos y luego presionar el botón Conectarse,
después presionar el botón Valores, el primer método en el componente n_operaciones_ciclo
es llamado. Esto crea la instancia de un componente y es ligado a una sesión cliente. Los
valores ingresados en los sigle-line edit son pasados a la función y este valor es almacenado
en las variables de instancia en el componente. Después de llamar a la función of_valores y
luego que es completada, el componente es desactivado y no es ligado a una sesión cliente
(vea la figura 5.12). Desde que no se soporta el instance pooling, la instancia del
componente es destruida (esto se muestra en la figura 5.9).
Figura 5.12
_____________________________________________________________________________________________
Cuando el botón Procesar es presionado, una nueva instancia del componente,

n_operaciones_ciclo, es creado y ligado a una sesión cliente como se muestra en la
figura 5.13.
Figura 5.13
La segunda llamada al método del componente stateless
Sin embargo, la llamada a la función of_calculo retorna nulo porque los valores que
fueron puestos por la llamada a la función of_valores fue perdida cuando la primera
instancia fue destruida. Se puede señalar otra vez que el cliente puede llamar a las
funciones of_valores y of_calculo usando una sola referencia al objeto proxy. La
habilidad del cliente para llamar a los métodos en el componente n_operaciones_ciclo
no fue afectado por el stateless. El servidor Jaguar maneja la creación y activación del
componente para la llamada transparente de cada método. La figura 5.14 muestra que
después de que la llamada a la función of_calculo se completa, el componente
también es desactivado y destruido.
Figura 5.14
El Runtime monitor después de que el botón Procesar es presionado
_____________________________________________________________________________________________
Manejando estados para los componentes stateless
Los componentes stateless son desactivados después de cada llamada a un método.

Cualquier información que es almacenada, calculada, o recuperada como resultado de la
llamada de un método es perdida cuando el proceso de la función es completada. Puede
requerirse información de una llamada de la función, sin embargo, puede requerirse en las
llamadas subsecuentes de los métodos. Cuando desarrollamos componentes stateless, es a
menudo importante manejar la información entre las llamadas de los métodos. Para
asegurarse que la información necesita de la llamada de un método para el siguiente
componente stateless está habilitado, existen muchas estrategias que pueden ser
empleadas.
Las primeras técnicas son obligar a la aplicación cliente para manejar los estados pasando
todos los valores pertinentes atrás a la aplicación cliente. Los valores pueden enviarse al
servidor como argumentos de función cuando el siguiente método es invocado. Esta técnica
es una de las más fáciles de implementar, pero tiene varias desventajas. El primero es el
incremento en el uso de la banda de red debido a pasar grandes cantidades de información
de un lado a otro entre el servidor y la aplicación cliente. La red entre el cliente y el servidor
es típicamente una WAN, especialmente para aplicaciones de internet. Estos son los más
frecuentes pero hay mayores distancias y tráfico que estos.
Esto también requiere que las funciones de los componentes acepten los argumentos para
los estados de los datos. Cuando un componente requiere información adicional, la función
debe ser modificada para aceptar nuevos argumentos, que también requiere un cambio en la
aplicación cliente, algo que será evitado en una arquitectura distribuida.
La segunda técnica es almacenar los valores de paso para un almacenamiento persistente

facilitado en el servidor. Es a menudo en una base de datos, pero también podrían usarse los
archivos. Esta técnica limita el tráfico de la red entre el cliente y el servidor de aplicaciones,
pero incrementa el número de hits en el servidor de la base de datos. Esto también puede
requerir tablas especiales para los estados que deben ser construidos y mantenidos como
parte de la base de datos.
Componentes Stateful Versus Stateless
Es importante comprender la diferencia entre los componentes stateless y stateful como se

muestra en la tabla 5.1 y su impacto en el desarrollo. La habilidad para almacenar
información entre las llamadas de los métodos es frecuentemente tomada para aplicaciones
cliente/servidor o DPB. En una aplicación distribuida como el EAServer o Web, los objetos
stateless son importantes para proveer un estado especial de escalabilidad y el manejo de
los procesos que se debe requerir para manejar el almacenamiento de información entre
llamada de métodos.
Tabla 5.1 Componentes Stateful Versus Stateless
Stateful Stateless
_____________________________________________________________________________________________
Las intancias son ligadas al cliente Las instancias son ligados a los
por periodos largos clientes por periodos cortos
el servidor tiene instanciado más el servidor tiene instanciados menos
instancias instancias
las instancias son reusadas muy las instancias son más reusados
poco el servidor requiere de pocos
el servidor requiere más recursos, recursos
limitando la escalabilidad
Es recomendado el uso de componentes stateless, porque no consumen muchos recursos

del servidor como se detalla en la lista de comparación.
Desactivación Temprana
Un componente que soporta la desactivación temprana es un componente híbrido que es

parte stateful y parte stateless. La desactivación temprana es usada para describir
componentes que entran en la fase de desactivación después de la llamada de un método
por la invocación de alguna función del transaction primitive, que se muestran en la tabla 5.2.
Tabla 5.2 Funciones primitives del TransactionServer
Función Acción
SetComplete( ) Desactiva el componente
SetAbort( ) Desactiva el componente
EnableCommit( ) No Desactiva el componente
DisableCommit( ) No Desactiva el componente
Nota: estas funciones son cubiertas en el capítulo 8.
La fácil desactivación puede ser usada para implementar un componente stateless, pero es
más fácil de hacer esto usando la opción Automatic demarcation/deactivation que codificar la
llamada al SetComplete o a un SetAbort en cada método.
La fácil desactivación es usada para componentes que realizan procesos o transacciones

con muchos métodos pero pueden ser desactivados después de que el proceso es
finalizado. Por ejemplo, en el ejemplo aplicación usando el componente EAServer
n_operaciones_ciclo se debería desactivar el componente después de llamar a la función
of_calculo después de realizar el proceso.
Para desactivar la instancia después de la invocación de la función of_calculo, adicionar la

llamada a la función of_desactivar como se muestra en el siguiente código :
// of_calculo
//argumento : (reference) string as_operador
CHOOSE Case as_operador

Case ‘+’
Il_resultado = ii_valor1 + ii_valor2
Case ‘-’
Il_resultado = ii_valor1 - ii_valor2
Case ‘*’
Il_resultado = ii_valor1 * ii_valor2
Case ‘/’
Il_resultado = ii_valor1 / ii_valor2
END CHOOSE
this.of_desactivar()
RETURN Il_resultado
_____________________________________________________________________________________________
Retornando al Runtime Monitor del EAServer, vea que después de presionar el botón
Valores la instancia del componente EAServer es desactivado después de que la función
of_valores ha finalizado (vea la figura 5.15).
Figura 5.15
Después de presionar el botón Procesar, la instancia del componente EAServer es

desactivado (vea la figura 5.16). una vista general del servidor Jaguar es mostrada en
la figura 5.10, las llamadas subsiguientes a la función of_calculo deberían retornar
nulo.
Figura 5.16
El Runtime monitor después de presionar el botón Procesar
La fácil desactivación puede ser usada para componentes que necesitan tener muchas
llamadas a métodos en sucesión, mientras mantienen su estado o una transacción para
completar una tarea. Estos métodos deberían ser llamados tan rápidamente para que la
instancia del componente pueda liberarse. También se puede poner la propiedad del
instance timeout property para que un componente use la fácil desactivación, para
prevenir el memory leaks del EAServer.
_____________________________________________________________________________________________
Instance pooling
La opción Instance pooling ayuda a reducir el gasto de recursos en el servidor eliminando la

necesidad de crear una nueva instancia del objeto, siempre que un objeto se use, se permite
reusar las instancias de los componentes, esto es similar al pool de conexiones de la base de
datos.
Sin el instance pooling, una instancia de un componente es destruida luego de ser

desactivada. Cuando el instance pooling es soportado, la instancia es movida al pool en lugar
de ser removida de la memoria. Cuando se usa un componente stateless, esto puede
mejorar la performance desde que los objetos stateless son activados y desactivados
después de cada llamada a un método. Si la instancia del objeto siempre es destruida
después de la desactivación, una nueva instancia debe ser creada en memoria para cada
llamada de un método.
Esto es importante para notar que el instance pooling determina como los componentes son
manejados después de que estos son desactivados. El Instance pooling, sin embargo, no
determina si un objeto es stateless o no. Se recomienda que soporte el instance pooling para
ayudar a incrementar la escalabilidad.
Soportando el instance pooling
Los componentes EAServer pueden soportar el instance pooling de una de estas dos
maneras. La manera más fácil de soportar el instance pooling en un componente
EAServer es habilitar la opción instance pooling. Cuando esta opción es habilitada, el
componente automáticamente es pooled después de que la instancia del componente
es desactivada.
Un componente PowerBuilder puede ser configurado para soportar el instance pooling

habilitando la opción instance pooling en el objeto project antes de desplegar el
objeto. esta opción en el proyecto debe habilitar la opción pooling como se muestra en
la figura 5.17, cuando se ha hecho deploy al componente.
Figura 5.17
Habilitando la opción instance pooling
Otra manera para habilitar el componente EAServer para soportar el instance pooling, es
abrir el Jaguar Manager y encontrar el componente dentro del package donde ha sido
_____________________________________________________________________________________________
instalado. Abrir la ventana de diálogo de las propiedades del componente resaltando el

nombre del componente y presionando el botón derecho con el mouse. Seleccione la opción
Component Properties... del menú popup y haga click en el tab Instance (vea la figura 5.18).
Activar la opción Pooling y presionar Aceptar para grabar. Para asegurarse que esta opción
tomó efecto, encontrar el nombre del servidor dentro del fólder de Servers en el Jaguar
Manager, y refrescar el servidor.
Figura 5.18
El instance pooling habilitado en el Jaguar Manager
Cuando la opción instance pooling es soportado, las instancias de un componente son

siempre reusadas y el servidor Jaguar no llama al evento CanBePooled después de
que el componente ha sido desactivado. si la opción instance pooling no es soportada,
el valor de retorno del evento CanBePooled determina si la instancia del componente
debe ser reusada después de la desactivación. Un valor de retorno de uno (1) causará
que la instancia será reusada, y un valor de retorno cero (0) causará que la instancia
sea destruida. Cuando el evento CanBePooled no ha sido escrito, la instancia de un
componente no será reusada, este evento es mostrado en la figura 5.19.
Figura 5.19
El evento CanBePooled
Técnicas para construir y reusar componentes
Un componente que soporte el instance pooling debe poder inicializarse cuando se activa y
limpiarse cuando se desactive. Esto asegura que la siguiente sesión cliente que recibe la
instancia no tiene datos de otras llamadas de métodos por un cliente diferente.
_____________________________________________________________________________________________
En el evento Active es donde el desarrollador debería poner las rutinas de inicialización, este
evento es llamado para inicializar la instancia. Todo el código para limpiar el componente
debería ser ubicado en el evento Deactivate. Este código podría normalmente ser ubicado en
el evento Destructor, pero este evento es llamado cuando el objeto es destruido, el
componente no debe ser limpiado después de ser asignado a una nueva sesión cliente.
El código que típicamente puede ser encontrado en el evento Activate incluye la creación de
un objeto TransactionServer y una conexión a una base de datos. El evento Deactivate
típicamente limpia los valores de todas las variables de instancia, destruye cualquier objeto
creado por el componente, destruye el objeto TransactionServer, y hace la desconexión de la
base de datos.
Propiedad Instance timeout
La propiedad del componente Instance Timeout es usado para especificar cuanto tiempo una
instancia de un componente estará activo y ligado a una sesión cliente sin una llamada a un
método antes de ser desactivada por el servidor Jaguar. Cuando la propiedad Instance
Timeout se pone a un valor mayor que cero, asegura la desactivación de un componente
stateful y previene el memory leaks del Jaguar.
Figura 5.31
Configurando la propiedad timeout del componente
La configuración del Instance Timeout puede ser puesta en el proyecto del componente
EAServer poniendo el timeout del componente mayor que cero, como se muestra en la figura
5.31. La configuración del Instance Timeout activa la propiedad timeout,
com.sybase.jaguar.component.tx_timeout.
La propiedad Instance Timeout de un componente puede también ser puesta en el Jaguar

Manager. Para poner la propiedad Instance Timeout de un componente, abrir el Jaguar
Manager y presionar el fólder Servers. Expandir el fólder Installed Packages y encontrar el
package donde el componente ha sido instalado. Expandir el package y resaltar el nombre
componente, como se muestra en la figura 5.32.
Figura 5.32
Accediendo a un componente
_____________________________________________________________________________________________
Presionar el botón derecho del mouse para acceder al menú popup y seleccionar Component
Properties... para abrir el diálogo de las propiedades del componente como se muestra en la
figura 5.33. seleccionar el tab All properties y encontrar la propiedad del Instance Timeout.
Com.sybase.jaguar.component.timeout
Figura 5.33
Propiedades del componente: All Properties
Presionar el botón Modify para cambiar el valor. La ventana de diálogo del modify
Property es mostrada en la figura 5.34. ingrese el valor del Instance Timeout, que es
representada en segundos, y presione OK para grabar.
Figura 5.34
Modificando las propiedades del Instance Timeout
_____________________________________________________________________________________________
Resumen
Controlar el ciclo de vida de los componentes es un factor importante en el desarrollo de las

aplicaciones distribuidas, esto nos permite tener una mejor performance en nuestra
aplicación, poder reusar los objetos que están creados en memoria, el diseño de los
componentes Stateless y Stateful, permiten hacer que nuestras aplicaciones puedan ahorrar
el consumo de los recursos de nuestros servidores, asimismo las opciones del Instance
Pooling y del Timeout nos dan la posibilidad de poder controlar la creación y destrucción de
nuestros objetos.
El lector debe comprender que teniendo en cuenta el ciclo de vida podrá tener mejores
respuestas de sus aplicativos a desarrollar.
_____________________________________________________________________________________________

Manejando Ciclos de Vida de Componentes Easerver PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manejando Ciclos de Vida de Componentes Easerver PDF

Cargado por

Copyright:

Formatos disponibles

Ciclo de Vida de los Componentes | 1

El ciclo de vida del Componente EAServer

• Alcance general del ciclo de vida del Componente EAServer

Manejando el comportamiento de los componentes

PowerBuilder provee un ideal ambiente de desarrollo para construir los componentes

Los Componentes EAServer

El ciclo de vida (life-cycle) del componente EAServer

Eventos del ciclo de vida de componentes EAServer

Un componente puede implementar los eventos del ciclo de vida de EAServer, a

El evento Constructor es invocado cuando el componente es inicialmente creado (primer

El evento Activate es invocado cuando el componente es ligado al cliente y es usado para

El evento Deactivate es invocado cuando el componente es desligado del cliente y es usado

El evento Destructor es invocado cuando el componente es destruido, este evento es

Diseñando los componentes

Los componentes pueden ser diseñados como:

Configurando un componente para ser stateful

El solo requerir configurar para crear un componente stateful requiere deshabilitar la

• Poner la propiedad Automatic demarcation/deactivation desactivada

Un ejemplo de un componente stateful

Debemos primero abrir el workspace techera5.pbw que se encuentra en el directorio

Debemos de abrir el objeto n_operaciones_ciclo, y debemos de verificar que las variables de

El componente n_operaciones_ciclo debe tener tres funciones: of_valores, of_calculo, y

La función of_valores permite a la aplicación cliente pasar los valores al componente y

CHOOSE Case as_operador

Il_resultado = ii_valor1 - ii_valor2

Antes de ejecutar la aplicación cliente, inicializar el Jaguar Manager y abrir el Runtime

muestra la llamada a la función of_valores y también muestra al componente como está

Cuando el botón Procesar es presionado, la función of_calculo es llamado y el valor del

Un componente que es desactivado después de cada llamada a un método es stateless. La

Configurando un componente para ser stateless

La única configuración necesaria para crear un componente stateless es habilitar la

Un componente PowerBuilder puede ser stateless habilitando la opción Automatic

fólder Servers en el Jaguar Manager y refrescar el servidor, para seleccionar refrescar en el

Un componente EAServer también puede ser implementado como un componente

Ahora debemos de ejecutar el último ejemplo usando un componente stateless. Poner el

Cuando el botón Procesar es presionado, una nueva instancia del componente,

Manejando estados para los componentes stateless

Los componentes stateless son desactivados después de cada llamada a un método.

La segunda técnica es almacenar los valores de paso para un almacenamiento persistente

Componentes Stateful Versus Stateless

Es importante comprender la diferencia entre los componentes stateless y stateful como se

Tabla 5.1 Componentes Stateful Versus Stateless

Es recomendado el uso de componentes stateless, porque no consumen muchos recursos

Un componente que soporta la desactivación temprana es un componente híbrido que es

Tabla 5.2 Funciones primitives del TransactionServer

Nota: estas funciones son cubiertas en el capítulo 8.

La fácil desactivación es usada para componentes que realizan procesos o transacciones

Para desactivar la instancia después de la invocación de la función of_calculo, adicionar la

CHOOSE Case as_operador

Después de presionar el botón Procesar, la instancia del componente EAServer es

La opción Instance pooling ayuda a reducir el gasto de recursos en el servidor eliminando la

Sin el instance pooling, una instancia de un componente es destruida luego de ser

Soportando el instance pooling

Un componente PowerBuilder puede ser configurado para soportar el instance pooling

instalado. Abrir la ventana de diálogo de las propiedades del componente resaltando el

Cuando la opción instance pooling es soportado, las instancias de un componente son

Técnicas para construir y reusar componentes

Propiedad Instance timeout

La propiedad Instance Timeout de un componente puede también ser puesta en el Jaguar

Controlar el ciclo de vida de los componentes es un factor importante en el desarrollo de las

También podría gustarte