|
Yo he leido que no se deberían registrar mas de 20 eventos en una aplicación...
En una aplicación de pruebas, registra solo el evento que te interesa (update de la tabla en cuestión) y fíjate si la velocidad de respuesta aumenta.
También he de decir algo sobre el commit en servidores Windows:
He visto algunas veces, con mi aplicación corriendo en varios ordenadores, que un ordenador hace un update de varias tablas y su correspondiente commit, pero en los demás ordenadores no se refleja el cambio hasta después de unos 10 segundos. A pesar de que el ordenador que hizo los cambios los ve inmediatamente.
Esto no me ha sucedido nunca con servidores Linux.
Nunca supe a qué era debido esto.
Por lo tanto:
- Mira si la aplicación que ejecuto el stored procedure ve los cambios inmediatamente.
- Si es un stored procedure pesado, mira si después del commit, el servidor sigue cargado (CPU al 99%) aunque la aplicación ya tenga el control. Puede que esté enviando el evento a los ordenadores.
MIRA ESTO PRIMERO:
Otra cosa que se me ocurre ahora:
- Supón que pones el evento OnUpdate en una tabla detalle.
- Supon que tienes una cabecera con 20 detalles
- Haces un update de la cabecera y esta a su vez, a traves de triggers hace update de detalle.
- Haces commit.
Mientras se están haciendo los updates de los 20 detalles no recibirás ningún evento.
Recién cuando hagas el commit, recibirás 20 eventos.
Si tu Stored Procedure genera muchos eventos, puede que esté tardando porque tiene que enviarle muchos eventos a muchos ordenadores.
|