Ha “ricontrollato Locking” work in ColdFusion?

Question

Ho usato una versione del doppio checked bloccaggio nella mia CF app (prima di sapere cosa bloccaggio doppio controllo era).

In sostanza, controllo per l'esistenza di un oggetto. Se non è presente, chiudo (di solito utilizzando un blocco di nome) e prima di cercare di creare l'oggetto verifico per esistenza di nuovo. Ho pensato che questo era un modo pulito per fermare più oggetti creati e smettere di bloccaggio eccessiva nel sistema.

Questo sembra funzionare, in quanto non v'è chiusura e oggetti eccessivi duplicati non vengono creati. Tuttavia, ho recentemente appreso che ricontrollato blocco lavoro dosn't in Java , quello che non so è se questo è vero in CF, visto che le discussioni CF e si blocca non del tutto sono le stesse di thread Java nativo e serrature.

Answer 1

Per aggiungere a quello che ha detto Ben Doom su Java, questa è una pratica abbastanza standard in ColdFusion, in particolare con una routine di inizializzazione applicazione in cui si impostano le variabili di applicazione.

Senza avere almeno un blocco, si sta lasciando i colpi iniziali per l'applicazione web tutto inizializzare le variabili di applicazione allo stesso tempo. Ciò presuppone che l'applicazione è occupato abbastanza per giustificare questo. Il pericolo è lì solo se l'applicazione è occupato al momento l'applicazione è prima in fase di avvio.

La prima serratura si assicura solo una richiesta alla volta inizializza le variabili.

La seconda serratura, inserita all'interno del primo, si verifica che una variabile definita alla fine del codice di inizializzazione esiste, come application.started. Se esiste, l'utente viene buttato fuori.

Il modello di doppia chiusura ha salvato la mia pelle su siti occupati, tuttavia, con siti molto occupato, la coda di richieste di colpo iniziale dell'applicazione per completare può salire troppo in alto, troppo in fretta, e causare il crash del server. L'idea è, le richieste sono in attesa del primo colpo, che è lento, allora la seconda rompe nel primo cflock, ed è rapidamente respinto. Con centinaia o migliaia di richieste in coda, in crescita ogni millisecondo, sono tutti incanalando verso il basso per il primo blocco cflock. La soluzione è quella di impostare un timeout molto basso sul primo cflock e non gettare (o prendere e anatra) l'errore di timeout di blocco.

Come nota finale, questo comportamento che ho descritto è stato deprecato con il metodo ColdFusion 7 del onApplicationStart () del vostro Application.cfc. Se si utilizza onApplicationStart (), allora non dovrebbe essere bloccabili tutti per la vostra routine applicazione init. Application.cfc è ben bloccato già.

Per concludere, sì, ricontrollato opere in ColdFusion bloccaggio. E 'utile in poche determinate circostanze, ma farlo bene. Non conosco gli schemi del perché funziona al contrario di modello di threading di Java, è probabile che sta controllando manualmente una sorta di tabella di ricerca in background del server ColdFusion.

Answer 2

Java è threadsafe, quindi non è tanto che le serrature non funzionerà come che non sono necessari. In sostanza, in CF 6+, sono necessari serrature per prevenire condizioni di gara o la creazione / althering oggetti che esistono al di fuori del controllo di Java (file, ad esempio).

Answer 3

Per aprire tutto un altro vaso di Pandora ...

Perché non si utilizza una libreria di Dependency Injection, come ad esempio Coldspring, per tenere traccia degli oggetti e prevenire le dipendenze circolari.