Etiqueta

14 agosto 2014

SQL en modo multitarea y multi-hilo (Parte 8 de 8)

Eliminación de procesos en ejecución


Durante el tiempo que un “Interface Object” esté operativo será posible invocar sus métodos $init() y $start(), aún en el caso de que el “Worker Object” esté ejecutando una tarea anterior. En este caso, será su propiedad $waitforcomplete quien determine si el proceso en ejecución debe continuar hasta completarse o no, informando al “Interface Object” de su finalización.

Si $waitforcomplete es kFalse, el proceso en ejecución será desligado del “Interface Object”, tal y como si estuviera a punto de quedar huérfano, sin embargo, lo que sucede, es que se crea un nuevo objeto “Worker Delegate” que será utilizado para la ejecución de la nueva tarea, con la capacidad necesaria para informar  al “Interface Object” de su finalización.

Si $waitforcomplete es kTrue, El “Worker Main” o objeto “worker” en uso, devolverá un error al “Interface Object” ante cualquier intento de volver a utilizarlo, mientras sucede que aún está en ejecución su “Worker Delegate” correspondiente. En estos casos, los objetos “worker” no pueden ser re-utilizados hasta que se produce el correspondiente $completed()/$cancelled(), será su propiedad $state quién podrá indicar su finalización.

Para entender mejor su funcionamiento, podríamos decir que un objeto “worker” con su propiedad $waitforcomplete fijada como kFalse, se convierte a todos los efectos en una especie de “dispara y olvídate”, lo cual causa que, por ejemplo, una sucesión de sentencias INSERT, UPDATE o DELETE sean remitidas al servidor de forma continua y en hilos de ejecución separados desde un único objeto.


Cancelación de procesos huérfanos


Si no se indica lo contrario (por defecto), a los subprocesos que han quedado huérfanos se les permite llegar hasta su terminación. No obstante, en algunos casos puede ser preferible emitir una solicitud para su cancelación, ($cancelled) especialmente si se estaba ejecutando una sentencia SELECT, ya que sabemos que no podremos recuperar su resultado por haber quedado desligado de su “Interface Object”. Esto se logra mediante fijar la propiedad $cancelifrunning a kTrue, antes de que el objeto “worker” sea reutilizado o destruido.

La propiedad $cancelifrunning es por defecto kFalse, por lo tanto, los subprocesos que han quedado huérfanos son ejecutados por completo antes de desecharse sus resultados y ser destruidos por el objeto “Thread Timer”.

12 agosto 2014

SQL en modo multitarea y multi-hilo (Parte 7 de 8)

Procesos “worker” huérfanos


Al lanzarse un $start(), el “Worker Delegate” se encargará de que se complete la tarea antes de invocar a los métodos del “Interface Object” $completed() o $cancelled(). Si se trata de un $run(), el “worker” será bloqueado para prevenir su cancelación, por lo que el método $completed() siempre será invocado.

Sin embargo, en caso de un $start(), el “Interface Object” puede quedar legítimamente desligado (huérfano) del “worker”, de lo contrario correría el riesgo de ser destruido antes de terminar la tarea que se le ha encargado ejecutar como subproceso. En éste momento, podemos decir que el subproceso no posee objeto alguno, se ha quedado huérfano y, por tanto, no es posible la invocación de los métodos $completed()/$cancelled(). En éste caso tanto los resultados como la información sobre posibles errores se descartarán.


 Proceso “Worker Delegate” huérfano. El “Interface Object” puede quedar desligado de su “Delegate”, y por lo tanto apuntar ahora hacia un nuevo “Worker Delegate”.

Tras la destrucción de un “Interface Object”, se transfiere la propiedad del “Worker Delegate” al “Thread Timer”. Un sólo objeto “Thread Timer” lleva acabo la supervisión de todos los objetos “Worker” de un determinado tipo, encargándose de eliminar los que hayan podido quedar huérfanos una vez concluidas sus tareas.

Un solo objeto “Thread Timer” supervisa todos los “Worker Delegates” de un determinado tipo. Un “Interface Object” sólo puede iniciar y recibir resultados de un único “Worker Delegate”, aunque pueden coexistir múltiples “Interface Objects”

01 agosto 2014

SQL en modo multitarea y multi-hilo (Parte 6 de 8)

Funcionamiento de los objetos “SQL worker”


El objeto “worker” puede ser representado mediante tres sub-objetos:

  • Interface Object
    Es el objeto no-visual estándar Omnis que proporciona los métodos y propiedades ya descritos anteriormente.

  • Worker Delegate Object
    Es el encargado de crear y ejecutar el subproceso en segundo plano. El “Worker Delegate” realiza el trabajo real del objeto “worker”, invocando al “Interface Object” cada vez que concluye.

  • Thread Timer Object
    Declarado estáticamente, cada “Worker Delegate” “suscribe” (por decirlo así) al ejecutarse ($start) un objeto “Timer Thread” (control multi-hilo). Todos los subprocesos poseen algún tipo particular de “Thread Timer”, el cual es responsable de que se vuelva a invocar su correspondiente “Interface Object”, tras concluir su ejecución.


Detrás de cada objeto “SQL Worker”, se esconde un “Worker Delegate” y un “Thread Timer”