En realidad, hay una pequeña posibilidad de una condición de carrera en un sitio de subastas a menos que realmente esté programando mal. Me pregunto si te equivocas en cuanto a qué condición de carrera es. No tiene nada que ver con el hecho de que las personas están “compitiendo” para obtener la última oferta.
Por ejemplo, la manera más fácil de garantizar que no haya condiciones de carrera sería crear un registro separado para cada oferta. Así es como la mayoría de la gente pensaría hacerlo de todos modos. Incluso en un nivel de actividad de eBay, esto no crearía suficientes datos para abrumar al servidor de la base de datos, y siempre podría eliminar las ofertas antiguas si fuera necesario.
Una condición de carrera ocurre cuando dos procesos intentan actualizar el mismo dato. Es por eso que, si tiene registros separados para cada oferta, nunca podría tener una condición de carrera, a menos que una persona intentara actualizar su información de perfil o detalles de la subasta, y por alguna razón intentara hacerlo en dos computadoras diferentes al mismo tiempo vez, presione el botón de enviar exactamente al mismo tiempo, e incluso entonces, tendría que tener un momento increíblemente desafortunado. E incluso si sucedieran todas esas cosas desafortunadas, una condición de carrera probablemente ni siquiera resultaría en que ocurriera algo malo.
- Cómo vincular archivos PHP y SQL existentes para crear una página web
- Desarrollé un marco de JavaScript que creo que es mejor en todos los sentidos, forma y forma que cualquier otro marco existente. ¿Debo cobrar por la licencia?
- Sé React y React-Redux junto con AJAX y Jquery. He realizado múltiples proyectos pero no puedo atraer a ningún reclutador. ¿Qué pasos tomo?
- Quiero hacer un sitio web de tutoriales que también tenga mensajes sociales y foros. ¿Hay algún script PHP gratuito para esto?
- ¿Por qué necesito un servidor para usar una base de datos?
Así es como ocurre una verdadera condición de carrera y por qué puede ser mala:
Digamos que está creando un sitio de comercio electrónico pesado y, en particular, desea realizar un seguimiento de los niveles de existencias. Como cada artículo en su tienda es un registro, usted decide agregar un campo a ese registro de artículo llamado NumberInInventory. Entonces, alguien pone un registro de Widgets y dice que tenemos 10 en stock. Cada vez que se compra un widget, primero consulta el registro para averiguar cuál es NumberInInventory, resta uno y escribe ese nuevo número en el campo NumberInInventory. El problema surge cuando te quedan 2 existencias y dos personas deciden comprar una exactamente al mismo tiempo (por ejemplo, en milisegundos entre sí). La persona A presiona Comprar, la computadora lee el campo NumberInInventory y obtiene 2. Luego, antes de que la computadora pueda restar 2–1 (pista, eso es bastante rápido), la Persona B presiona Comprar y la computadora, en un hilo diferente, lee el campo NumberInInventory y obtiene 2. Luego el hilo de la Persona A resta 2-1 y obtiene 1, que luego escribe en el campo NumberInInventory. Luego, el hilo de la Persona B resta 2-1 y obtiene 1, que luego escribe en el campo NumberInInventory.
Por lo tanto, a pesar de que tenía un inventario de 2 y dos personas cada uno compró uno, la base de datos todavía cree que tiene uno en el inventario, e intentará venderlo, lo que obviamente puede causar algunos problemas.
Pero el punto es que esto solo puede suceder cuando ambos intentan actualizar el mismo dato y cuando también intentan actualizarlo con un valor que depende de un estado anterior de esos datos. Si dos personas intentaran actualizar el nombre del elemento, por ejemplo, no podría existir una condición de carrera.
Técnicamente, también puede obtener condiciones de carrera actualizando campos separados en el mismo registro al mismo tiempo, solo en función de cómo funciona el funcionamiento interno de la base de datos, pero de nuevo, todo esto se mitiga simplemente usando registros separados y en línea sitio de subastas, no hay una razón real para no hacerlo.
