| Re: [riena-dev] Riena-Singletons |
|
Hi, I don´t think we can trust in stateless services. For example
there is the EventAdmin-Service which is ThreadSafe but as it comes from the
OSGi-Layer and not the application it is shared among application and
registered in the one FrameWork-instance. If I am a consumer of events
delivered by the EventAdmin I need to be sure that events come from my
application. What if I dynamicly register services for a special usecase in
my application? That means the availability of the service depends on the use
case. You could not implement this without having application-dependant
services.. In my opinion every service is a candidate for singletons. On
the other hand I understand that turning all services into singletons would be
very expensive (time consuming) .. :-/ -Heiko Von:
riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Campo, Christian Hi Stefan, I dont think Services are Singleton. For example you can
have multiple service instances for the same interface. I think OSGi Services
are something like the way we use stateless remote services. Remote Services on
the server are also used by many many users and are written so that they are
thread-safe. If we have OSGi Services in Riena they need to be stateless
services (which might not be true today). I believe it would be the wrong approach
to change the service model for the purpose of using RAP..... just my 2 cent christian Am 16.09.2010 um 10:51 schrieb Liebig, Stefan:
Hi Rienars, Aren´t OSGi services not some other kind of singletons? I know they have a much nicer name but like a singleton a
service exists only once in a JVM and can be shared from multiple clients. If such a service has session dependent state we have to take
care of it. Does RAP provide any patterns for dealing with session dependent
services? Tschüß, Stefan Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von Liebig, Stefan Hi
Rienaers, While
working thru our code base I have detected several kinds of
"singletons" (some of them I would not call them a singleton): 1. the classical singelton - a single instance
of class (maybe created lazily or not) with the typical static getInstance()
method (sometimes it has a different name) with fields (state) 2. the static singleton - this a class with
only static methods and static fields carrrying some state 3. the pseudo classical singleton - a single
instance of a class with getInstance() but without fields (state) 4. the utility singleton - a class with only
static methods without fields (state) 1.
and 2. are "real" singletons (they have some state). At these
singletons we need to look a little bit closer when we also want to use them
within RAP. For them we can use SessionSingletonProvider and SingletonProvider. How
about 3. and 4., especially 3. ? Should
we transform 3 to 4 (no more getInstance(), just static methods)? Or
… Should
the getInstance() method always be named getInstance()? Opinions,
feedback, .. Tschüß, Stefan ------------------------------------------------------------- fon: +49 (0) 69 / 27 22 18 0
<ATT00001..c> |