Cómo actualizar singleton en C#

Question

Tengo singleton que se obtiene de DB, por lo tanto, es una carga costosa. Tiene una carga lenta.

Me gustaría crear un método que refresque ese singleton y lo rellene una vez que se requiera.

los datos son DB y muy caros, por lo que quiero actualizarlo solo una vez en caso de que tenga llamadas concurrentes. (Es decir, si consigo 500 llamadas para refrescar, deseo reiniciar la actualización sólo una vez)

public static PageData Instance 
    { 
     get 
     { 
      if (m_Instance == null) 
      { 
       lock (instanceLock) 
       { 
        if (m_Instance == null) 
        { 
         m_Instance = new PageData(); 
        } 
       } 
      } 
      return m_Instance; 
     } 
    } 


public void ReSync() 
     {       
      lock (instanceLock) 
      { 
       /* Setting to null to force the Instance to re-build */ 
       m_Instance = null; 
       PageData pData = Instance; 
      } 
     } 

gracias

Answer 1

Esta cifra es ligeramente incorrecto, su

if (m_Instance == null)

debe realmente estar en el interior de la cerradura.

Disculpe, no lo vi.

No hay nada incorporado que pueda hacer que otros clientes abandonen las llamadas en silencio si ya se está refrescando. Los tiempos de espera generarán una excepción, creo. Quizás mantenga un DateTime obsoleto que pueda verificar para evitar hacer la actualización en las llamadas en cola.

Answer 2

Aparte de la double-checked locking se rompa (corrección, al parecer it does work pero todavía me resulta no especialmente bonita), si tiene acceso de escritura a m_Instance ¿por qué no ponerlo en nueva PageData() en el acto en RESYNC?

Answer 3

Qué tal si incluye un miembro "lastRefreshed" que también verifica y bloquea durante la actualización. Entonces, si la última actualización ocurrió dentro del tiempo X, ¿no volverá a suceder?

Answer 4

Si usted quiere que cumple con el modelo de memoria ECMA, supongo que la aplicación debe ser algo como esto (suponiendo m_Instance no es volátil):

public static PageData Instance 
{ 
    get 
    { 
     PageData instance = Thread.VolatileRead(ref m_Instance); 
     if (instance == null) 
     { 
      lock (instanceLock) 
      { 
       instance = Thread.VolatileRead(ref m_Instance); 
       if (instance == null) 
       { 
        instance = new PageData(); 
        Thread.VolatileWrite(ref m_Instance, instance); 
       } 
      } 
     } 

     return instance; 
    } 
} 

public void ReSync() 
{ 
    /* Setting to null to force the Instance to re-build */ 
    Thread.VolatileWrite(ref m_Instance, null); 
    PageData pData = Instance; 
} 

Si ha definido m_Instance siendo volátil sólo hay una diferencia principal. El m_Instance debe leerse en la variable local antes de realizar la comprobación nula, porque el método ReSync() puede establecer la variable compartida como nula. También eliminé el bloqueo de ReSync() ya que no es realmente necesario. La carrera para inicializar una nueva instancia es segura.

Answer 5

Según tengo entendido, ¿espera llamadas simultáneas al método Resync? Esto realmente no debería suceder si lo llamas solo una vez en 500 solicitudes de clientes. Sin embargo, tal vez sea mejor idea no solo bloquear el bloqueo de instancia, porque entonces singleton sería reinstalado varias veces de todos modos, pero no en el "mismo" momento.

public void ReSync() 
{ 
    if (!m_IsResyncing) 
    { 
    lock (m_resyncLock) 
    { 
     if (!m_IsResyncing) 
     { 
     m_IsResyncing = true; 
     Thread.Sleep(100); // sleep for 100ms to accumulate other locks 
     // reinitialize here 
     m_IsResyncing = false; 
     } 
    } 
    } 
} 

Answer 6

Según tengo entendido, esto debería funcionar.

Aquí está mi código:

private static instanceLock = new object(); 
private static _refreshing = true; 

public static PageData Instance 
    { 
     get 
     { 
      if (_refreshing) 
      { 
       lock (instanceLock) 
       { 
        if (_refreshing) 
        { 
         m_Instance = new PageData(); 
         _refreshing = false; //now allow next refreshes. 
        } 
       } 
      } 
      return m_Instance; 
     } 
    } 


public void ReSync() 
     { 
      if (!_refreshing)       
       lock (instanceLock) 
       { 
        if (!_refreshing) 
        { 
         _refreshing = true; //don't allow refresh until singleton is called. 
        } 
       } 
     } 

Answer 7

puedo necesitar para entender mejor cómo el concurrancy vino a este. Su descripción parece encajar en el alcance del espacio de nombres System.Cashing. Usted dice que el objeto debe almacenar su información por un período de tiempo (algunas opciones están disponibles allí).

Si la siguiente solicitud es la misma que la anterior (usted mismo define los criterios de 'identic'), la persona que llama obtendrá la copia en caché. En realidad, significa que no hay una nueva conexión db. Solo una solicitud de memoria. Si los criterios de caché válidos han pasado, es decir, 30 minutos, la siguiente solicitud se realizará contra la base de datos (durante otro período de tiempo).

Requiere memoria pero es extremadamente rápido y se recomienda en escenarios donde se reutilizan datos.