Strict versus NonStrict Estrategias de concurrencia de caché NHibernate

Question

Esta pregunta trata acerca de la diferencia entre las estrategias de concurrencia de caché de ReadWrite y NonStrictReadWrite para la memoria caché de segundo nivel de NHibernate.

Según tengo entendido, la diferencia entre estas dos estrategias es relevante cuando se tiene una distribución replicado caché - no estricta no garantizará que un caché tiene el mismo valor exacto como otra memoria caché, mientras estricta lectura/escritura debe - suponiendo que el proveedor de caché realiza el bloqueo distribuido apropiado.

La parte que no entiendo es cómo la distinción estricta vs no estricta es relevante cuando tiene una sola memoria caché, o una distribuida caché (no replicada). ¿Puede ser relevante? Me parece que en los escenarios no replicados, el caché de marcas de tiempo garantizará que los resultados obsoletos no se sirvan. Si puede ser relevante, me gustaría ver un ejemplo.

Answer 1

Lo que asumes es correcto, en un solo entorno de destino/subproceso, hay poca diferencia. Sin embargo, si nos fijamos en los proveedores de caché, está sucediendo algo incluso en un escenario de subprocesos múltiples.

La forma en que se vuelve a almacenar en caché un objeto desde su estado modificado es diferente en el caso de no estricto. Por ejemplo, si su objeto es mucho más recargable para volver a cargar, pero le gustaría después de una actualización en lugar de ubicar al próximo usuario con la factura, entonces verá un rendimiento diferente con estricto y no estricto. Por ejemplo: no estricto simplemente descarga un objeto de la memoria caché después de realizar una actualización ... se paga el precio de la recuperación en el siguiente acceso en lugar de un controlador de eventos posterior a la actualización. En el modelo estricto, el re-caché se ocupa automáticamente. Algo similar sucede con las inserciones, las no estrictas no harán nada donde estricto irá detrás y cargará el objeto recién insertado en la memoria caché.

En no estricto también tiene la posibilidad de una lectura sucia, ya que la caché no está bloqueada en el momento de la lectura no se vería el resultado de otro cambio de hilo en el elemento. En estricto, la clave de caché para ese elemento se bloquearía y usted sería retenido, pero verá el último resultado absoluto.

Por lo tanto, incluso en un entorno de destino único, si hay una gran cantidad de lecturas/ediciones simultáneas en objetos, entonces tiene la oportunidad de ver datos que no son realmente precisos.

Esto, por supuesto, se convierte en un problema cuando se realiza una operación de guardado y se carga una pantalla de edición: la persona que piensa que está editando la última versión realmente no lo está, y se sorprenderá cuando intentan guardar las ediciones en los datos obsoletos que cargaron.

Answer 2

He creado una publicación here que explica las diferencias. Por favor, eche un vistazo y siéntase libre de comentar.