Come fare un Singleton con ambito oggetto thread-safe (Guice + Owasp ESAPI)

Question

Attualmente sto usando OWASP ESAPI per gestire l'autenticazione nella mia applicazione Java Web, e sto iniettando il MyAuthenticator Singleton con guice.injectMembers (questo). Vorrei fare un passo lontano da questo approccio e utilizzare un oggetto Singleton con ambito Guice-creato. Mi è piaciuto il thread-sicurezza del Singleton ESAPI, e la sicurezza dei single in generale, usando ricontrollato Locking, IODH Idiom, o lo stile Enum GRADO di Bloch.

Che cosa devo fare per la mia Guicified Singleton con ambito Authenticator per renderlo thread-safe, così come il campo ThreadLocal che sto usando per ottenere e impostare il mio attuale utente?

Mi piacerebbe fare l'intero lavoro di applicazione con la dipendenza-iniezione, ma non vogliono la rottura su web-app di accessi contemporanei. Eventuali suggerimenti o problemi comuni?

L'oggetto ThreadLocal sto usando sembra che il codice qui sotto:

private final ThreadLocalUser currentUser = new ThreadLocalUser();

private class ThreadLocalUser extends InheritableThreadLocal<User> {

    @Override
    public User initialValue() {
        return User.ANONYMOUS;
    }

    public User getUser() {
        return super.get();
    }

    public void setUser(User newUser) {
        super.set(newUser);
    }
}

Answer 1

Purtroppo non so abbastanza di Owasp ESAPI per dare una risposta specifica, ma si può avere una certa fortuna esaminando il supporto AOP di Guice. È possibile intercettare tutte le chiamate di metodo sulla classe e di fornire qualunque comportamento concorrenza ti piace.

http://code.google.com/p/google-guice/ wiki / AOP

Answer 2

Attenzione utilizzando il "doppio-Check Locking" pattern in Java. Questo modello di progettazione non funziona correttamente in Java (per esempio, vedere http : //www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html ) meno si dichiara l'istanza Singleton come " volatili " .