Supongamos que eres paranoico y doblemente paranoico cuando se trata de subprocesos múltiples. Suponga que está haciendo el backend de alguna funcionalidad de la aplicación, y la aplicación extrae periódicamente algunos métodos en sus servidores. Todo parece ir bien, pero hay un pero. ¿Qué pasa si su funcionalidad depende directamente de algunos otros datos, el mismo perfil banal por ejemplo? La pregunta es cómo asegurarse de que el guión funcione exactamente como lo planeó y no haya sorpresas. ¿Actas? Sí, se puede usar, pero ¿qué pasa si eres un paranoico fantástico y ya te imaginas cómo 10 solicitudes al mismo método de diferentes clientes vuelan a tu servidor y todas estrictamente al mismo tiempo? Y en este momento, la lógica empresarial de este método está vinculada a 100.500 datos diferentes. ¿Cómo gestionas todo esto? Puedes sincronizar el método y listo.Pero, ¿qué pasa si también hay esas solicitudes que no tiene sentido cumplir? Aquí ya empiezan las muletas. Ya hice una pregunta similar un par de veces, y fue interesante, porque la tarea es absurdamente simple y cotidiana (si te importa que no haya errores lógicos, por supuesto). Hoy decidí pensar en cómo se puede implementar esto de manera muy simple y sin muletas. Y la solución salió literalmente en 100 líneas de código.
Un pequeño ejemplo ilustrativo
Supongamos que hay un conductor y un pasajero. El conductor no puede cambiar el coche hasta que el cliente, por ejemplo, confirme el viaje. ¿Resulta que el cliente accedió a un viaje con las mismas características del coche, pero en realidad el conductor tiene un coche diferente? ¡No lo hagas! Puedes organizar algo como esto:
String result = l.lock(new ArrayList<Locker.Item>() {{
add(new Locker.Item(SimpleType.TRIP, 1));
add(new Locker.Item(SimpleType.USER, 2));
}}, () -> {
//
// - - USER=2 (),
// - TRIP=1
// USER=3, :)
// :)
return " :)";
});
¡Elegante y simple!
¡No arrojes piedras! )