11 - La Forja: peticiones que llegan a la vez

La API funciona de maravilla… con un usuario. El programa del paso 02 era secuencial: una acción a la vez. Ahora cada petición vive en su hilo, y todos los hilos tocan el mismo bean de repositorio. El paso aplica los conceptos del tema: pool de hilos de Tomcat y estado compartido. Aquí no se implementa nada: el entregable es un diagnóstico.

• Averiguar cómo atiende la app sus peticiones: qué hilo las recibe, dónde se ve, cuántos hilos da el pool y cuántos se reutilizan.
• Diseñar un experimento que demuestre el estado compartido: dos o más peticiones que tocan el mismo dato a la vez (el caso clásico: dos registros de héroe solapados) y registrar lo que se observa.
• Diagnosticar los puntos de la app donde el estado es compartido: qué dato vive solo para un hilo (y por tanto está seguro) y qué dato comparten todos — y qué consecuencia *actual* o *futura* tiene en cada uno.
• El entregable es un informe breve (los tres puntos anteriores), que se defiende en clase. El código de la app no cambia en este paso: detectar, no arreglar.

• El pool de hilos de Tomcat: configurado en `application.properties` (mínimo de hilos preparados y máximo del pool) — se ajusta para el experimento si hace falta apurar el diagnóstico.
• La observación del log del servidor para ver qué hilo atendió cada petición (`http-nio-8080-exec-N`).
• Peticiones simultáneas lanzadas en paralelo desde el terminal (`&` y `wait`), varias seguidas y varias a la vez, para comparar.
• El recordatorio del tema: dónde vive cada cosa y a quién se comparte:

• ¿Cuántas peticiones y cómo se lanzan para demostrar la reutilización y para demostrar el acceso simultáneo? ¿Y cómo distingues ambas cosas en el log?
• ¿Qué dato compartido observas en el experimento y qué estropea cuando se solapan dos peticiones? (El contador de ids del paso 03 es candidato).
• El experimento tiene que llegar a intensidad suficiente: si no falla, ¿es que no hay condiciones de carrera o es que el estímulo no da para tanto?
• ¿Qué situaciones de La Forja no necesitan control porque su estado es local, y cuáles sí deberían preocuparte?

• El informe nombra el mecanismo (pool + hilos reutilizables) y muestra la evidencia del log que lo demuestra: misma petición hilo distinto, peticiones seguidas con hilo igual.
• El experimento propuesto es reproducible: otro compañero lo lanza y observa algo parecido.
• La condición de carrera se explica con la causa: las tres operaciones de que se compone un ++ (leer, sumar, guardar) y por qué solapadas producen resultados imposibles (ids repetidos, plantilla inconsistente).
• El inventario de estado compartido cubre los puntos de la app: repositorio, contadores, colecciones, cualquier static que quedara de la historia consola.
• El informe separa lo que es problema hoy de lo que lo será cuando llegue el paso 12 — el contexto por petición es un caso aparte.

El paso 12 realmente necesita un valor por hilo (la identidad autenticada de cada petición). Ahí es donde ThreadLocal —y su limpieza— entra en escena con el modelo correcto.