Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Heyho,
ich schreibe gerade eine Webanwendung. Und dabei habe ich eine Liste erstellt (ArrayList) und mir wurde auch Vector vorgeschlagen. Allerdings war ich mir gar nicht mehr so sicher was der Unterschied gewesen ist, also fragte ich google. Da erfuhr ich, das Vector multithreading unterstützt und Array List nicht. Habe außerdem gelesen das eine Webapp automatisch einen neuen Thread startet wenn die Seite von einem neuen User aufgerufen wird. Heißt das nun ich muss Vector benutzen? Oder muss ich Vector nur nehmen, wenn ich explizit Threads in der Anwendung erstelle und mit diesen auf Vectoren zugreife? Begeife das nicht 100%.
Aktuell denke ich nämlich jeder User hat nen eigenen "main thread" indem seine anwendung läuft und deshalb reicht da array list. Es ist trotzdem multi threading, weil ja jeder user so einen Thread bekommt, aber in diesem Main Thread gibts ja keine weiteren und deshalb brauche ich da keine threadsicheren objekte. Aber wenn ich in diesem main thread nochmal threads erstelle, dann brauche ich in der Anwendung, ne nachdem welche Objekte ich verwende, thread sichere objekte und methoden. Korrekt? Freue mich auf Hilfe und Antworten
Die Frage ist, ob mehrere Threads auf die ArrayList zugreifen können. Beispiele:
Du hast die ArrayList als eine lokale Variable in einer Methode (z.B. der Methode, die bei einem Request aufgerufen wird und die den Request behandelt) erstellt. Hier kann kein anderer Thread drauf zugreifen.
Du hast eine ArrayList in einer Instanzvariable gespeichert, und die Instanz wird an mehreren Stellen benutzt (Weil es in einer @Component, @Service, .... ist). Hier ist es dann nicht thread sicher, daher wird das hier kritisch.
Die Frage ist, ob mehrere Threads auf die ArrayList zugreifen können. Beispiele:
Du hast die ArrayList als eine lokale Variable in einer Methode (z.B. der Methode, die bei einem Request aufgerufen wird und die den Request behandelt) erstellt. Hier kann kein anderer Thread drauf zugreifen.
Du hast eine ArrayList in einer Instanzvariable gespeichert, und die Instanz wird an mehreren Stellen benutzt (Weil es in einer @Component, @Service, .... ist). Hier ist es dann nicht thread sicher, daher wird das hier kritisch.
Kann der zweite Fall überhaupt auftreten? Sollen Componenten , Services, Repositorys die man an verschiedenen Stellen autowiren kann nicht eh stateless sein? Also dürfen eh keine Instanzvariablen haben mit ausnahme von final? Oder habe ich das falsch verstanden?
Das ist keine zwingende Regel. Daher schreibst Du ja auch ein "sollen" - was ja ganz deutlich was anderes aussagt als ein "müssen".
Und ich wäre da vorsichtig, da irgendwelche Regeln aufstellen wollen ... und hier im Forum bin ich noch sehr viel vorsichtiger wenn es darum geht, das User ggf. machen.
Und natürlich: auch finale Variablen sind kein Garant für Unveränderlichkeit. Eine final List kannst Du nicht ersetzen, aber die Elemente verändern.
Das ist keine zwingende Regel. Daher schreibst Du ja auch ein "sollen" - was ja ganz deutlich was anderes aussagt als ein "müssen".
Und ich wäre da vorsichtig, da irgendwelche Regeln aufstellen wollen ... und hier im Forum bin ich noch sehr viel vorsichtiger wenn es darum geht, das User ggf. machen.
Und natürlich: auch finale Variablen sind kein Garant für Unveränderlichkeit. Eine final List kannst Du nicht ersetzen, aber die Elemente verändern.
Wenn es keine Zwang regel ist dann wäre interessant wann die Ausnahme denn auftreten würde. Wann wäre es gut und vorteilhaft nen Service nicht stateless zu machen? Ich mache es immer. Würde also gerne wissen unter welchen Umständen man state in solchen Objekten haben soll.
Es kommt darauf an, was die Aufgabe des Services ist. Wenn es einfach nur der 2. Tier in einer 3-Tier Anwendung mit View/Presentation Layer, Business Logik Service-Layer und Persistence Layer ist, dann ist ein "Service" nur die Implementierung einer Geschäftslogik und bedient sich selbst wiederum der Persistenzschicht und/oder anderen Services.
Es gibt aber auch Querschnittsaspekte wie etwa Metriken, die dein Server über sich selbst sammeln will (wie etwa Anzahl Requests/Aufrufe), um diese z.B. in einem bestimmten Format nach Außen verfügbar zu machen. Hier ist der "State" eben alle aktuell aufgezeichneten Werte der Metriken. Diese werden üblicherweise auch nicht jedesmal über die Persistenzschicht in eine Datenbank geschrieben.
Ein weiteres Beispiel wäre z.B. Caching. Auch, wenn es natürlich auch z.B. in Spring und Third-Party Libraries Support für Caching gibt, könnte man aber eben solchen "Zustand" eines Caches innerhalb eines Services halten, um etwa zukünftige Anfragen/Berechnungen zu beschleunigen.
Jetzt könnte man aber auch noch fragen: Was verstehen wir eigentlich wirklich unter "stateful" bzw. nicht stateless? Wenn deine Anwendung in einem Service z.B. zum Startpunkt der Anwendung einmal etwa eine ArrayList mit Einträgen in-memory vorberechnet, weil sie die Daten später braucht (also quasi auch Cache bzw. Memoization), diesen Zustand aber niemals später verändert, ist der Service dann stateful? Letztlich kann der State hier auch als weitere (konstante) Abhängigkeit des Services gesehen werden.
Es kommt darauf an, was die Aufgabe des Services ist. Wenn es einfach nur der 2. Tier in einer 3-Tier Anwendung mit View/Presentation Layer, Business Logik Service-Layer und Persistence Layer ist, dann ist ein "Service" nur die Implementierung einer Geschäftslogik und bedient sich selbst wiederum der Persistenzschicht und/oder anderen Services.
Es gibt aber auch Querschnittsaspekte wie etwa Metriken, die dein Server über sich selbst sammeln will (wie etwa Anzahl Requests/Aufrufe), um diese z.B. in einem bestimmten Format nach Außen verfügbar zu machen. Hier ist der "State" eben alle aktuell aufgezeichneten Werte der Metriken. Diese werden üblicherweise auch nicht jedesmal über die Persistenzschicht in eine Datenbank geschrieben.
Ein weiteres Beispiel wäre z.B. Caching. Auch, wenn es natürlich auch z.B. in Spring und Third-Party Libraries Support für Caching gibt, könnte man aber eben solchen "Zustand" eines Caches innerhalb eines Services halten, um etwa zukünftige Anfragen/Berechnungen zu beschleunigen.
Jetzt könnte man aber auch noch fragen: Was verstehen wir eigentlich wirklich unter "stateful" bzw. nicht stateless? Wenn deine Anwendung in einem Service z.B. zum Startpunkt der Anwendung einmal etwa eine ArrayList mit Einträgen in-memory vorberechnet, weil sie die Daten später braucht (also quasi auch Cache bzw. Memoization), diesen Zustand aber niemals später verändert, ist der Service dann stateful? Letztlich kann der State hier auch als weitere (konstante) Abhängigkeit des Services gesehen werden.
Danke für die ausführliche Antwort Denke ich verstehe was du meinst und beende die Diskussion hier nun, da sie sich von der Ursprungsfrage entfernt. Danke @httpdigest , @KonradN für die Rückmeldungen. Schönen Sonntag noch !
