# EJB3.0 vs Spring Beans bzw. EJB3.1 - Vorteil von Singleton vs. Pool



## damien (8. Feb 2010)

Hallo,

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 ?

Gruß


----------



## byte (8. Feb 2010)

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.

Hier gibts interessante Infos, nicht nur zur Ebay Plattform: High Scalability - High Scalability - eBayArchitecture



> ...
> #  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.
> ...


----------



## damien (8. Feb 2010)

Interessant, schaue ich mir gleich durch, danke !

Aber meine Frage bzgl. Singleton vs. Pool hast du nicht direkt beantwortet


----------



## byte (8. Feb 2010)

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.


----------



## damien (8. Feb 2010)

D.h. Singleton macht bei Stateful Session Beans wenig Sinn, bei Stateless schon eher ?


----------



## Deadalus (23. Feb 2010)

damien hat gesagt.:


> D.h. Singleton macht bei Stateful Session Beans wenig Sinn, bei Stateless schon eher ?



Ä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?


----------



## damien (26. Feb 2010)

Naja nicht wirklich, es gibt weiterhin Stateful und Stateless Session Beans, die du zusätzlich mit @Singleton annotieren kannst.


----------

