Every event executes in a thread of its own. Let's create a bad event that causes an infinite loop to run in the background.En el ejemplo crearán un ciclo infinito para demostrar que cada evento es ejecutado en un hilo específico. El código es como sigue:
DELIMITER // CREATE PROCEDURE pe () BEGIN x: LOOP ITERATE x; END LOOP; END// CREATE EVENT ee ON SCHEDULE EVERY 2 SECOND COMMENT 'This is a bad idea' DO CALL tp.pe() // DELIMITER ; SET GLOBAL event_scheduler = 1;Luego, la documentación continúa explicando cómo ver los resultados y comprobar que, efectivamente, el evento es ejecutado en su hilo correspondiente. Sin embargo, contrario a lo que se pueda pensar mirando el código, el procedimiento será ejecutado solo una vez, y no múltiples veces cada 2 segundos. Con respecto a esto, la documentación explica:
You might wonder: why does this happen only once? Why doesn't the scheduler start a new thread every minute? Well, if we did things that way, then a bad event like this one would cause the scheduler to try to set up an infinite number of threads. So we decided that if a recurring event is still executing when it's time to do it again, the server won't open another thread and try to execute the event again.O sea que, MySQL, previendo que un evento pueda ejecutar algún tipo de código incorrecto, no creará otro hilo para volver a ejecutar el evento si la llamada anterior aún no ha finalizado. La joya de la explicación es el siguiente párrafo con el que concluyen el tema:
Naturally this exercise is strictly theoretical, since nobody would ever make a bad event. That's why database administrators sleep well at night.Sarcásticos... Por supuesto que todo el tiempo se crearán eventos incorrectos. Está en el día a día de la profesión y de nuestra condición humana equivocarnos, así que el ejercicio dista mucho de ser "estrictamente teórico" como dicen, pero un poco de humor de vez en cuando no viene mal.
Bromas aparte, la lección de esta historia se centra en cómo debemos preparar nuestras aplicaciones anticipándonos a cualquier tipo de interacción por parte de los usuarios. Si asumimos en que los clientes de nuestros sistemas van a guiarse siempre por "las reglas", terminaremos con un producto mediocre bien por debajo de un estándar aceptable.
Como se dice en la jerga informática, los clientes pueden ser idiotas (sin ánimos de ofender a nadie, recuerdo que yo también soy cliente de cientos de aplicaciones), lo que provoca que sea imposible preever sus acciones en nuestro sistema. Tenemos que estar preparados para cualquier cosa y jamás asumir que "nadie es tan tonto de hacer algo como eso". Aunque solo sea como un mero ejercicio "estrictamente teórico".
Gracias a David Newmon por enviarme la página de la documentación de MySQL y enseñarme el ejemplo. No creo que sin usar Google Translate pueda leer este post, pero de todos modos aquí está.
Exactamente pasa lo mismo en SQL Server, si tienes un job corriendo, y segun el schedule es hora de correr de nuevo, SQL Server no lo vuelve a ejecutar.
ReplyDeleteAsí debiera ser todo: actuar proactivamente ante cualquier problema potencial.
ReplyDelete