Frühjahr: Singleton/session Bereiche und Parallelität

Tut singleton/session Bereiche der Spring-Bean erforderlich, die den Zugriff auf alle seine Felder, die synchronisiert werden müssen? Sagen durch "synchronized" - Schlüsselwort oder mit einigen Klassen aus dem Paket "java.util.concurrent".

Als Beispiel, ist dieser code nicht thread-sicher? (kopieren/erzählt von hier):

@Component
@SessionScoped
public class ShoppingCart {
    private List<Product> items = new ArrayList<Product>();

    public List<Product> getAllItems() {
        return items;
    }

    public void addItem(Product item) {
        items.add(item);
    }
}
InformationsquelleAutor Alex Siman | 2009-11-17
  1. 24

    Wenn Sie singleton Rahmen von der Spring-container, den Sie zeigen, dass alle threads, die das abrufen der bean aus dem container, wird die gleiche Instanz. Also in diesem Fall, wo der Staat die Liste der Artikel ist freigegeben und modifizierbaren zwischen threads, Sie würde haben Sie Zugriff auf die Liste zum Schutz Ihrer Applikation gegen eine ConcurrentModificationException.

    Jedoch die übliche Praxis mit Feder ist, um Ihre Anwendung mit stateless-Objekte, die nicht Staat ändern sich im Laufe der Lebensdauer der Anwendung.

    Im Fall von session Umfang, könnten Sie weniger wahrscheinlich, um zu sehen, eine Parallelität problem, da die Bohne nur zugänglich ist durch den aktuell angemeldeten Benutzer. Jedoch, es ist möglich (zumindest im web) zu haben, mehrere Anfragen auf der gleichen Sitzung, in welchem Fall würden Sie brauchen, um die gleichen Vorsichtsmaßnahmen wie wenn die Bohnen waren ein singleton.

    Wieder der beste Weg, sich zu schützen, ist, zu versuchen, halten Sie Ihr bean als stateless wie möglich. Wenn Sie eine bean, die erfordert Zustand, sollten Sie mithilfe der prototype Umfang, der ruft eine neue Instanz der bean vom container jeder Zeit.

    InformationsquelleAutor Jason Gritman
  2. 0

    Der Benutzer nur für diese Sitzung kann der Zugriff auf diese Klasse, aber ArrayList ist nicht thread-safe ist, wie gesehen, in dieser Diskussion: http://forums.sun.com/thread.jspa?threadID=5355402

    Müssen Sie sicherstellen, dass Ihre Klasse ist vollständig thread-sicher, da SessionScoped wird nur sichergestellt, dass es nur von jeder Sitzung, so eine Sitzung kann nicht darauf zugreifen.

    Möchten Sie vielleicht Blick auf die Kommentare in dieser Diskussion für mehr info:
    http://wheelersoftware.com/articles/spring-session-scoped-beans.html

    InformationsquelleAutor James Black
  3. -4

    Grundsätzlich für jeden Benutzer, der eine Sitzung initiiert eine neue ShoppingCart erstellt und bezieht sich auf diese Sitzung pro Benutzer.

    Ihrer Klasse ist thread-sicher. Die Initialisierung 

    private List<Product> items = new ArrayList<Product>();

    ist eine thread-sichere Initialisierung und

    addItem(Product item) ist eine Atomare operation, und ist daher auch thread-safe.

    • Wenn jemand anruft, getItems() und beginnt, Durchlaufen ihn, während gleichzeitig ein anderer thread eine Methode addItem(), wirst du barf eine ConcurrentModificationException. Siehe java.sun.com/javase/6/docs/api/java/util/ArrayList.html für sich Notizen auf, was synchronisiert werden muss für die thread-Sicherheit mit ArrayList.
    • Die Klasse ist nicht thread-sicher, weil 'items' Sammlung ist sicher nicht publiziert; Artikel.add() bietet keine Garantie, dass seine Wirkung ist sichtbar an den thread, als das aktuelle, und es ist nicht atomar.
    • Hmmm ich hatte den Eindruck, dass die Tatsache, dass die Klasse auch SessionScoped und können nur gehandelt werden, die von einem einzigen Akteur innerhalb des Spring-Containers wäre sicherzustellen, dass die thread-Sicherheit der Klasse?
    • Ich denke, es könnte sicher gemacht werden, wenn die Klassen CopyOnWriteArrayList verwendet wird
    InformationsquelleAutor non sequitor
Schreibe einen Kommentar