Resumen

  • RFC 2372 aconsejó crear un registro de recuperación antes de PREPARED y otro antes de COMMIT en estado Prepared, conservándolos hasta recibir evidencias de resolución distintas para cada rol.
  • La regla describía una custodia duradera, pero no demostraba que los bytes llegaran al medio estable, que sobrevivieran a una caída, que reapareciera la identidad correcta o que el cliente conociera el desenlace.

Un participante que todavía no ha dicho PREPARED puede abortar después de un fallo. El que ya lo dijo ha cedido esa libertad. El superior puede haber reunido los votos y decidido confirmar. Desde ese instante, la memoria local deja de ser comodidad técnica y se convierte en una obligación frente a otra máquina.

Publicado en julio de 1998 como RFC Informational, RFC 2372 explicó escenarios, requisitos y datos complementarios de implementación para TIP. No era un estándar de Internet ni un informe de despliegue. Incluso calificó de orientativa, no definitiva, su relación entre acciones del protocolo y registros. Precisamente por ello conviene leerlo con rigor: señaló qué debía existir, no probó que una implementación real lo hubiera conseguido.

El subordinado debía crear un prepared-recovery record antes de emitir PREPARED. Debía conservarlo hasta ABORT, COMMIT o QUERIEDNOTFOUND, y no enviar COMMITTED ni NOTRECONNECTED mientras siguiera allí. El superior recibía PREPARED y, antes de emitir COMMIT desde ese estado, debía crear un commit-recovery record. Este permanecía hasta COMMITTED o NOTRECONNECTED.

La secuencia describe traspasos de responsabilidad. PREPARED ata al participante a una futura decisión ajena. COMMIT ata al superior a una decisión que quizá deba repetir tras el fallo. Borrar el registro equivale a declarar que una evidencia especificada ha cerrado la deuda. No es simple limpieza de archivos.

La respuesta negativa podía ser una prueba positiva

Después de perder la conexión, el superior podía enviar RECONNECT con el identificador de la transacción subordinada, recuperándolo del registro si era necesario. Un subordinado aún Prepared respondía RECONNECTED. Si ya había recibido COMMIT, enviado COMMITTED y olvidado la transacción acabada, respondía NOTRECONNECTED. Ese “no” no describía por sí solo una avería: dentro de la historia correcta podía demostrar que el trabajo ya había terminado.

El subordinado podía consultar al superior mediante QUERY. QUERIEDEXISTS significaba que la transacción seguía allí y que llegaría un RECONNECT. QUERIEDNOTFOUND permitía abortar porque el superior quizá había enviado ABORT, perdido ABORTED y olvidado después la transacción bajo el modelo presumed-abort. La ausencia sólo tenía significado al combinar rol, estado, identidad y secuencia.

Por eso restablecer TCP no era recuperar la transacción. El transporte volvía a unir extremos, pero no reconstruía el identificador correcto, la obligación pendiente ni la interpretación de un registro ausente. La recuperación necesitaba memoria local durable y evidencia remota, no sólo un socket sano.

Los recibos de borrado eran asimétricos. Para el subordinado, una decisión o el resultado de consulta que liberaba el estado preparado. Para el superior, la confirmación del participante o la imposibilidad específica de reconectar con un participante que ya había olvidado el estado concluido. Un temporizador, un reinicio o la presión de disco no figuraban como sustitutos.

RFC 2372 contempló tiempos de espera locales para limitar recursos bloqueados y resolver interbloqueos. La política de tiempo podía liberar recursos, pero el paso de los minutos no verificaba qué resultado se había reconstruido. Resultado de recursos, resolución del protocolo y conocimiento posterior eran capas diferentes.

Entre escribir y persistir había una máquina entera

“Crear un registro” parece una instrucción completa sólo mientras no se pregunta dónde viven los bytes. ¿En un búfer del proceso, en la caché del núcleo, en un journal, en el medio físico o en otra zona de fallo? ¿Qué confirma exactamente el almacenamiento? ¿Puede romperse la escritura? ¿Se puede localizar la transacción sin el índice volátil? ¿Puede un emisor asíncrono adelantarse y lanzar PREPARED?

El RFC no contestó esas preguntas, ni presentó un motor, una prueba de conformidad o un ensayo de corte eléctrico. Su obligación debía convertirse en código y someterse a fallos. La óptica de Heng Lu sobre la primacía del código en ejecución ayuda a mantener la diferencia: el texto define el orden; la evidencia operativa observa la escritura, interrumpe el proceso, reinicia, reconstruye la identidad, reconcilia al par y comprueba el recurso.

Tampoco basta con borrar después del mensaje correcto. Si la eliminación se hace durable antes que la transición correspondiente del gestor de recursos, el sistema conserva una nueva incoherencia. Si nunca borra, puede acumular obligaciones antiguas y retener recursos. La corrección reside en el vínculo comprobable entre el protocolo, el registro y el recurso.

Un cliente sin registro no era un sistema sin responsabilidad

El documento distinguió clientes ligeros y servidores completos. El cliente podía delegar la coordinación y prescindir de un registro transaccional propio. La responsabilidad no desaparecía: cambiaba de custodio. La auditoría debía seguirla hasta el servidor y preguntar qué objeto guardó, con qué identidad, antes de qué afirmación y después de qué recibo lo quitó.

La aplicación cliente conservaba otra incertidumbre. Podía solicitar commit, perder la respuesta final y no saber que la transacción había concluido. RFC 2372 dejó en la aplicación la tarea de averiguar el desenlace y sugirió que un registro de usuario específico de la implementación podía ayudar. El gestor de transacciones podía recuperarse correctamente mientras la persona o servicio que inició el trabajo seguía sin una respuesta de negocio.

Aquí está la separación frente al artículo ya publicado sobre RFC 2371. Aquél posee la tesis amplia de los dos canales y de COMMIT como algo distinto de un recibo comercial. Este análisis posee la cadena local de evidencia: registro prepared, registro commit, identidad recuperada y señal exacta que permite eliminar cada uno.

Los dos canales añadían una obligación de serialización. El gestor TIP no veía necesariamente las solicitudes de aplicación en vuelo. La aplicación no debía llamar a commit mientras quedaran solicitudes asociadas, ni responder positivamente a un socio antes de que el gestor local registrara la transacción. Un registro duradero no podía rescatar una decisión tomada sobre operaciones de negocio incompletas.

TLS protegía un borde, no toda la conclusión

La autenticación y autorización de la aplicación quedaban fuera de TIP. TLS podía autenticar extremos y cifrar comandos si se negociaba. Eso reducía el riesgo de órdenes no autorizadas o suplantación de un gestor, pero no probaba la escritura del registro, la autorización comercial, el cambio del recurso ni la aceptación del resultado por otro sistema.

En recuperación se necesitaban canal fiable e identidad correcta. Una petición autenticada sobre la transacción equivocada seguía siendo errónea; un identificador correcto aportado por un impostor seguía siendo peligroso. Evidencia de seguridad, evidencia de estado y autoridad de negocio no eran intercambiables.

La lectura por capas de realidad de Heng Lu evita comprimir una cadena larga en una sola palabra. Petición de aplicación, acción local, estado TIP, registro, confirmación de almacenamiento, mensaje, identidad recuperada, respuesta remota, resultado del recurso y conocimiento del cliente podían divergir. “Confirmado” podía ser cierto en una capa e incierto en la siguiente.

La especificación mínima dejó una decisión local y comprobable

RFC 2372 no impuso formato universal de log, base de datos, API o consola. La interoperabilidad requería comandos, roles, identificadores y significado de recuperación comunes, no el mismo sistema de almacenamiento. En la visión de especificación inicial mínima de Heng Lu, cada implementación conservó la decisión futura sobre su mecanismo local.

Esa libertad no rebajó la prueba. Un operador debía demostrar que el registro precedía al mensaje, sobrevivía a la pérdida de energía, reaparecía sin índices volátiles, se enlazaba con el recurso correcto y sólo desaparecía tras el recibo autorizado. Citar el RFC respondía qué debía hacerse; no respondía si se había hecho.

Los servicios distribuidos de hoy también hablan antes de fallar: aceptado, replicado, preparado, autorizado. Cada término crea una expectativa sobre lo que persistirá. La lección de RFC 2372 no es que un log vuelva verdadera la palabra, sino que toda palabra con efectos posteriores al fallo necesita una evidencia durable, inspeccionable y anterior a ella.

Fuentes