Hi,
Yes, services are not singletons. But they share a lot of
properties:
- global access point
- shared among multiple clients
- one instance (although you can have many service objects registered
under the same class name - not neccessarily an interface!)
I would not say that all Riena services should be stateless but
if the state is session dependent they need some adaptation. Whatever that
means!
And I just wanted to mention that we need to take care of such
services.
Tschüß,
Stefan
Von:
riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Campo, Christian
Gesendet: Donnerstag, 16. September 2010 11:37
An: Riena Developers list
Betreff: Re: [riena-dev] Riena-Singletons
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.....
Am 16.09.2010 um 10:51 schrieb Liebig, Stefan:
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?
Von: riena-dev-bounces@xxxxxxxxxxx [mailto:riena-dev-bounces@xxxxxxxxxxx] Im Auftrag von Liebig, Stefan
Gesendet: Montag, 6.
September 2010 14:58
An: Riena Developers list
Betreff: [riena-dev]
Riena-Singletons
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)?
Should
the getInstance() method always be named getInstance()?
-------------------------------------------------------------
compeople AG
Untermainanlage 8
60329 Frankfurt/Main
fon: +49 (0) 69 / 27 22 18 0
fax: +49 (0) 69 / 27 22 18 22
web: www.compeople.de
Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz
Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
Ust-Ident.-Nr: DE207665352
-------------------------------------------------------------
<ATT00001..c>
|