PiensoPienso: Cómo implementar semáforos en GeneXus?
Hay un determinado proceso que por su consumo no puedo permitir mas que tres ejecuciones simultaneas del mismo pues la performance de toda la aplicación se degrada hasta niveles no aceptables.
Dicho proceso, puede tener cortes o caídas que hagan que no termine en forma correcta.
Cuales son las posibles implementaciones con GeneXus para lograr un máximo de tres ejecuciones simultaneas?
Se valorarán las que maximicen la concurrencia y no provoquen bloqueos.
Para los que quieran les dejo el link de wikipedia sobre el tema y otro sobre mutex.
Creo que lo mejor sería no usar Genexus =)
ResponderBorrarImplementar semáforos nunca es un tema trivial...
ResponderBorrarUna posibilidad es como dice Anónimo, no usar GeneXus. Amplío un poco más. Se puede tener un proceso corriendo que sea el que larga a correr los otros, y se esté fijando si alguno terminó o se cayó para largar el siguiente.
Si es con GeneXus, podrías tener una tabla con tres registros, y antes de hacer nada buscar si hay alguno libre y hacer un update con algún id de proceso o algo. La consulta de si está libre tiene que ser con lock para que no se pise con otro proceso... Además el proceso debería actualizar cada cierto tiempo el registro para que los demás vean que todavía está vivo, y si pasa más de cierto tiempo sin actualizar otro puede tomar el semáforo.
Estoy tan lejos de Gx que me cuesta hasta teorizar. Pero por tirar un bolazo, haría que tres servicos en el Server corriendo el mismo programa hecho en Genexus, cada uno de los servicos chequea una tupla en la tabla de Marcos donde puede recibir parámetros también, el cliente que quiere correr el proceso, cambia una flag en la primer tupla disponible de la table y espera a que la tupla sea liberada por el server. Las tuplas podrían tener el flag en libre, procesando y datos disponibles. El cliente pasaría nuevamente la tupla de datos disponibles a libre una vez que haya consumido el resultado del proceso en el server.
ResponderBorrarNecesitaríamos también contemplar las caídas de los servicos en el server y de los clientes esperando el resultado, pero bue, tampoco da para pensar tanto. :P
La idea es mover un poco las neuronas con problemas que parecen sencillos pero tiene sus sutilezas.
BorrarLos semaforos o los mutex, son muy necesarios en los desarrollos de sistemas grandes y con mucha concurrencia, pero hacer solucione que funcionen bien, no es trivial, por eso planteo el problema, para intercambiar algunas ideas.
vengo medio tarde con el blog. :)
ResponderBorrarlo que se me ocurre es usar el file system para manejar semáforos, lo que haces es que cada proceso cree y abra un archivo y que cuando finalice lo cierre, si se cae automáticamente libera el recurso y cualquiera podrá hacerle un delete, por lo que otros podrán estar esperando a que se pueda eliminar o que no exista el archivo para arrancar.
todo lo puedes hacer con GX sin usar nada por fuera.
usas el tipo xmlwriter para hacer la apertura del archivo y haces el close cuando quieras liberarlo.
Tienes también el tipo de datos file en los gx nuevos con opearaciones sobre el archivo para detectar si el archivo existe o está liberado (cualquier operación como delete o rename te daría un error, capturándolo te darás cuenta si está corriendo).
Puedes usar el WRKSTN() si es win, para saber qué puesto está trabajando y no hacer que el mismo se encuentre bloquedo.
ResponderBorrarYo tengo algo similar en una aplicación WEB tipo saas (con SessionId + IP) y funciona bien.
Usar XML o TXT como proponen creo que sería lo óptimo, pero hay que controlar el tema de las caías (por ej. con timestamp, o dar la posibilidad a un administrador de borrar el flag) para que no quede el flag colgado para siempre.
Salu2
Guillermo, la solución de usar file system es por el hecho de usar el mecanismo de lock de escritura de un archivo mientras está corriendo un proceso, al momento que el proceso cae se hace un close del archivo automáticamente y con eso se detecta si se hizo una caída, el sistema automáticamente detectará que puede hacer un delete, no se necesita de un administrador si está bien programada la lógica.
ResponderBorrarEnrique, la otra extra que se puede manejar es usar cola de mensajes, hacer que todos queden encolados y que el que procesa la cola solo pueda procesar de a 3 elementos al mismo tiempo, si tienes "un procesador" de estos pedidos son menos los que tienen que gestionar la concurrencia y caídas, simplemente los clientes esperan a que su procedimiento quede libre de la cola, siempre tendrás una concurrencia de tope de 3. Dependiendo de qué lógica de negocios sea, puedes hacerlo asíncrono, que el cliente sea notificado cuando su informe (proceso) terminó (o hacer la simulación sincrónica de un bucleo esperando a que el elemento sea procesado).
Cosas así implementé de todos los sabores, mediante un "demonio" que procesa una cola de mensajes (implementado mediante base de datos el sistema de cola y bloqueo), y otras similares mediante un workflow en donde el procesamiento de las tareas era de naturaleza asincónica (entonces se desencadenan automáticamente tareas, notidicaciones a medida que los trabajos terminan).
Cualquiera de ellos de alguna forma manejan cola de mensajes y tope en cantidad de procesos al mismo tiempo y funcionan bien, pero todo fue pensado para correr así de forma asincrónica (o fue modificado y adaptado para que corriera así, por lo que tienes la posibilidad de hacer las modificaciones para que pueda correr así).
Lo bueno del mecanismó de cola y procesamiento asincrónico es que no tienes usuarios "pegados" en la pantalla a que termine de procesar, pueden trabajar y hacer otras tareas mientras está procesando de fondo, termina y retoman el trabajo.
Esto lo pueden implementar también con el Workflow de Artech y el procesamiento de tareas de forma asincrónica en el servidor.