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.
EJB3.0 vs Spring Beans bzw. EJB3.1 - Vorteil von Singleton vs. Pool
was sind Vor- und Nachteile von einem Singleton Bean ? Das ist ja mit EJB3.1 eingeführt worden. Sind das Performancevorteile ?
Wann nimmt man nun eine Session Bean mit @Singleton und wann nimmt man eine ohne ? Bei 1000 Usern könnte ja eine mit @Singleton reichen, was ist aber bei einer riesen-Plattform wie z.B. ebay ? Sind da nicht mehrere Instanzen sinnvoll ?
Große Plattformen benutzen idR keine zustandsbehafteten Services wie Session Beans. Viele benutzen nicht mal EJBs. Ebay benutzt z.B. einfach nur zustandslose Servlets.
Das Zauberwort heisst Horizontal Scaling und Caching. Datenbanken sind häufig der Flaschenhals, während App Server und RAM billig und schnell sind. Daher kannst Du die Skalierbarkeit durch Load Balancing erreichen. Das klappt natürlich besser, wenn die Services zustandslos sind, denn nur dann ist es egal, mit welchem App Server zu kommunizierst. Datenbankzugriffe können durch Caching minimiert werden. Bei mehreren App Servern ist das Caching aber nicht mehr trivial.
...
# Move cpu-intensive work moved out of the database layer to applications applications layer: referential integrity, joins, sorting done in the application layer! Reasoning: app servers are cheap, databases are the bottleneck.
# No client-side transactions. no distributed transactions
# J2EE: use servlets, JDBC, connection pools (with rewrite). Not much else.
# No state information in application tier. Transient state maintained in cookie or scratch database.
# App servers do not talk to each other -- strict layering of architecture
...
Wenn Du in den Beans keinen Zustand speicherst, dann kannst Du überall Singletons verwenden. Vorteil ist halt, dass der Server nur ein Objekt erzeugen muss, was sich viele User teilen. Es muss auch nicht mehr für jeden User eine Session erzeugt und verwaltet werden. Ansonsten muss der Server halt bei jedem Request die Session ID auslesen und die entsprechende Session zuordnen. Daten in der Session belegen natürlich Heapspace. Und wenn man Load Balancing macht, muss man entweder die Sessions zwischen den App Servern propagieren, oder man muss bestimmte Session IDs immer wieder zum gleichen App Server lenken.
Nachteil einer komplett zustandslosen App-Tier ist, dass Du immer alle Informationen im Payload mitschleppen musst.
Ähm klärt mich auf wenn ich falsch liege. Ein Singelton ist docheine komplett neue Art von Bean. Mit anderen Worten es gibt jetzt Singteltons, Stateful Session Beans und Stateless Session Beans oder?
