Uso de agentes para completar efectos secundarios en transacciones de STM

Question

Soy consciente de que generalmente es una mala práctica poner funciones con efectos secundarios en las transacciones de STM, ya que se pueden volver a intentar y llamar varias veces.

Sin embargo, se me ocurre que podría usar agentes para garantizar que los efectos secundarios se ejecuten solo después de que la transacción se complete satisfactoriamente.

p. Ej.

(dosync 
    // transactional stuff 
    (send some-agent #(function-with-side-effects params)) 
    // more transactional stuff 
) 

¿Es esta una buena práctica?

¿Cuáles son los pros/contras/trampas?

Answer 1

original:

parece que eso debería funcionar para mí. Dependiendo de cuáles sean sus efectos secundarios, es posible que desee utilizar envío (para operaciones vinculadas a IO) en lugar de enviar (para operaciones vinculadas a CPU). El envío/envío colocará la tarea en uno de los grupos de ejecutores internos del agente (hay un grupo de tamaño fijo para la CPU y un grupo de tamaño ilimitado para las operaciones io). Una vez que la tarea está en cola, el trabajo está fuera del hilo de dosync, por lo que estás desconectado en ese punto.

Deberá capturar los valores que necesite desde dentro de la transacción hasta la función enviada, por supuesto. Y necesita lidiar con ese envío posiblemente ocurriendo varias veces debido a reintentos.

Update (ver comentarios):

agente envía dentro de la transacción de que el árbitro se llevan a cabo hasta que la transacción ref completa con éxito y se ejecuta una vez. Por lo tanto, en mi respuesta anterior, el envío NO ocurrirá varias veces, sin embargo, no ocurrirá durante la transacción de refuencia, que puede no ser lo que usted desea (si espera iniciar sesión o hacer algo con efecto secundario).

Answer 2

Esto funciona y es una práctica común. Sin embargo, como bien señaló Alex, debería considerar enviar más que enviar.

Existen más formas de capturar valores comprometidos y distribuirlos de la transacción. Por ejemplo, puede devolverlos en un vector (o un mapa o lo que sea).

(let [[x y z] (dosync 
       ; do stuff 
       [@x @y @z])] ; values of interest to sode effects 
    (side-effect x y z)) 

o puede llamar a restablecer! en un átomo local (definido fuera del alcance léxico del bloque dosync, por supuesto).

Answer 3

No hay nada de malo con el uso de agentes, pero basta con volver de los valores de transacción necesarios para el cálculo de efectos secundarios a menudo.

Las referencias son probablemente la forma más limpia de hacerlo, ¡pero incluso se puede gestionar con solo átomos!

(def work-queue-size (atom [0])) 

(defn add-job [thunk] 
    (let [[running accepted?] 
     (swap! work-queue-size 
       (fn [[active]] 
       (if (< active 3) 
        [(inc active) true] 
        [active false])))] 
    (println 
    (str "Your job has been " 
      (if accepted? 
      "queued, and there are " 
      "rejected - there are already ") 
      running 
      " total running jobs")))) 

El swap! puede volver a intentar tantas veces como sea necesario, pero la cola de trabajo nunca va a ser mayor que tres, y siempre se imprimirá exactamente una vez un mensaje que está ligado correctamente a la aceptación de su elemento de trabajo . El "diseño original" requería solo un int en el átomo, pero puede convertirlo en un par para pasar datos interesantes fuera del cómputo.