Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > StateFull vs Stateless Singleton

Reply
Thread Tools

StateFull vs Stateless Singleton

 
 
Pallav singh
Guest
Posts: n/a
 
      07-04-2010
Hi

what the consideration parameter to choose stateless and statefull
Singleton ?

Thanks
Pallav Singh
 
Reply With Quote
 
 
 
 
Francesco S. Carta
Guest
Posts: n/a
 
      07-04-2010
Pallav singh <(E-Mail Removed)>, on 04/07/2010 07:02:05, wrote:

> Hi
>
> what the consideration parameter to choose stateless and statefull
> Singleton ?


The mere need of a "stateless singleton" seems to be debatable - since
the things it can achieve can equally be achieved via regular functions
and static member functions - assuming I haven't completely
misunderstood them, any correction from better knowing will be welcome.

In any case, the considerations to make (in general) lie upon the
requirements of the single cases. Have you got any practical example to
consider?

--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
 
Reply With Quote
 
 
 
 
Öö Tiib
Guest
Posts: n/a
 
      07-04-2010
On 4 juuli, 17:02, Pallav singh <(E-Mail Removed)> wrote:
> Hi
>
> what the consideration parameter to choose stateless and statefull
> Singleton ?


Both are sort of java nonsense to achieve non-copyable global state or
global functions that java does not let you have otherwise. Global
state is bad design in all languages. Global functions are fine, but
you do not need singeltons for them in C++.
 
Reply With Quote
 
Trifle Menot
Guest
Posts: n/a
 
      07-04-2010
On Sun, 4 Jul 2010 08:42:25 -0700 (PDT), Öö Tiib <(E-Mail Removed)> wrote:

>Global state is bad design in all languages.


Not for small programs where you're the sole author. Things should be
as simple as possible.



--
Web mail, POP3, and SMTP
http://www.beewyz.com/freeaccounts.php

 
Reply With Quote
 
sebastian
Guest
Posts: n/a
 
      07-04-2010
On Jul 4, 9:02*am, Pallav singh <(E-Mail Removed)> wrote:
> Hi
>
> what the consideration parameter to choose stateless and statefull
> Singleton ?
>
> Thanks
> Pallav Singh


Neither - a simple template class eliminates the issue altogether:

<code>

#include <stdexcept>

template < typename Type >
class singleton
{
public:

singleton( void )
{
Type* ptr = static_cast< Type* >( this );
if( self )
{
/*
Or what have you...
*/
throw std::runtime_error
(
"Error: attempt to instantiate multiple instances of a singleton"
);
}
self = ptr;
}

static inline Type& instance( void )
{
return *self;
}

static inline bool exists( void )
{
return self != 0;
}

virtual ~singleton( void )
{
self = 0;
}

private:

singleton( singleton const& );

singleton& operator = ( singleton const& );

static Type* self;
};

template < typename Type >
Type* singleton< Type >::self = 0;

// Example:

#include <iostream>

class foo : public singleton< foo >
{
public:

void bar( void ) const
{
std::cout << "foo::bar( )" << std::endl;
}
};

int main( void )
{
try
{
foo a;
foo::instance( ).bar( );
foo c; // Whoops!
foo::instance( ).bar( );
}
catch( std::exception const& error )
{
std::cerr << error.what( ) << std::endl;
}
}

</code>

The beauty of the design is that it allows the user to decide how to
allocate and initialize the derived class; it's sole purpose is to
make sure that multiple instances aren't created. Best of all, it's
completely generic!

Cheers.
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      07-04-2010
On 4 juuli, 23:58, sebastian <(E-Mail Removed)> wrote:
> On Jul 4, 9:02*am, Pallav singh <(E-Mail Removed)> wrote:
>
> > Hi

>
> > what the consideration parameter to choose stateless and statefull
> > Singleton ?

>
> > Thanks
> > Pallav Singh

>
> Neither - a simple template class eliminates the issue altogether:
>
> <code>
>
> #include <stdexcept>
>
> template < typename Type >
> class singleton
> {
> * * * * public:
>
> * * * * singleton( void )
> * * * * {
> * * * * * * * * Type* ptr = static_cast< Type* >( this );
> * * * * * * * * if( self )
> * * * * * * * * {
> * * * * * * * * /*
> * * * * * * * * * * * * Or what have you...
> * * * * * * * * */
> * * * * * * * * * * * * throw std::runtime_error
> * * * * * * * * * * * * (
> * * * * * * * * * * * * * * * * "Error: attempt to instantiate multiple instances of a singleton"
> * * * * * * * * * * * * );
> * * * * * * * * }
> * * * * * * * * self = ptr;
> * * * * }
>
> * * * * static inline Type& instance( void )
> * * * * {
> * * * * * * * * return *self;
> * * * * }
>
> * * * * static inline bool exists( void )
> * * * * {
> * * * * * * * * return self != 0;
> * * * * }
>
> * * * * virtual ~singleton( void )
> * * * * {
> * * * * * * * * self = 0;
> * * * * }
>
> * * * * private:
>
> * * * * singleton( singleton const& );
>
> * * * * singleton& operator = ( singleton const& );
>
> * * * * static Type* self;
>
> };
>
> template < typename Type >
> Type* singleton< Type >::self = 0;
>
> // Example:
>
> #include <iostream>
>
> class foo : public singleton< foo >
> {
> * * * * public:
>
> * * * * void bar( void ) const
> * * * * {
> * * * * * * * * std::cout << "foo::bar( )" << std::endl;
> * * * * }
>
> };
>
> int main( void )
> {
> * * * * try
> * * * * {
> * * * * * * * * foo a;
> * * * * * * * * foo::instance( ).bar( );
> * * * * * * * * foo c; // Whoops!
> * * * * * * * * foo::instance( ).bar( );
> * * * * }
> * * * * catch( std::exception const& error )
> * * * * {
> * * * * * * * * std::cerr << error.what( ) << std::endl;
> * * * * }
>
> }
>
> </code>
>
> The beauty of the design is that it allows the user to decide how to
> allocate and initialize the derived class; it's sole purpose is to
> make sure that multiple instances aren't created. Best of all, it's
> completely generic!
>
> Cheers.


Looks as beautiful like any other reinvented square wheel. The
requirements seem to be that such code must work:

int main( void )
{
{
foo a;
foo::instance( ).bar( );
}
foo c; // Second singleton and *NO* Whoops
foo::instance( ).bar( );
}

Not sure why someone needs to have global state? Typical example of
singletons is a logger. Huh? So ... OK. What if i need to have
separate logs from different modules? I will then need new class for
each log to have separate singleton logger for each module? Nonsense.

What if i need to have separate logs from different threads? Then that
Logger::instance() should give me "different" singletons based on
thread ID? Huh? Why it can't just be debugging::log() and where it
logs is its internal business, no global state no nothing?

As for your code ... same thing with 10-12 lines instead of 70-80:

#include <iostream>
namespace foo
{
void bar()
{
std::cout << "foo::bar()" << std::endl;
}
}

int main()
{
foo::bar();
}

Things that contain nothing are not worth allocating or initializing.
 
Reply With Quote
 
Keith H Duggar
Guest
Posts: n/a
 
      07-05-2010
On Jul 4, 7:31*pm, Öö Tiib <(E-Mail Removed)> wrote:
> On 4 juuli, 23:58, sebastian <(E-Mail Removed)> wrote:
> > On Jul 4, 9:02*am, Pallav singh <(E-Mail Removed)> wrote:

>
> > > Hi

>
> > > what the consideration parameter to choose stateless and statefull
> > > Singleton ?

>
> > Neither - a simple template class eliminates the issue altogether:
> >
> > ...
> >
> > The beauty of the design is that it allows the user to decide how to
> > allocate and initialize the derived class; it's sole purpose is to
> > make sure that multiple instances aren't created. Best of all, it's
> > completely generic!

>
> Looks as beautiful like any other reinvented square wheel. The
> requirements seem to be that such code must work:
>
> ...
>
> Not sure why someone needs to have global state? Typical example of
> singletons is a logger. Huh? So ... OK. What if i need to have
> separate logs from different modules? I will then need new class for
> each log to have separate singleton logger for each module? Nonsense.


Yeah, it seems to me that singleton is the single most heavily
abused design pattern. Maybe because its name is "cool sounding"
and because it is easy to implement and because it allows one to
remain lazy maybe those are a trifecta of abuse temptations.

I think the only pattern I've seen nearly as heavily abused (but
at least not reimplemented as often) is shared_ptr where some crap
coder(s) spams every pointer as a shared_ptr because of irrational
fear and/or unwillingness (or inability) to design proper lifetime
management or to eliminate the need for such management entirely.

KHD
 
Reply With Quote
 
sebastian
Guest
Posts: n/a
 
      07-05-2010
On Jul 4, 6:31*pm, Öö Tiib <(E-Mail Removed)> wrote:
> On 4 juuli, 23:58, sebastian <(E-Mail Removed)> wrote:
>
>
>
> > On Jul 4, 9:02*am, Pallav singh <(E-Mail Removed)> wrote:

>
> > > Hi

>
> > > what the consideration parameter to choose stateless and statefull
> > > Singleton ?

>
> > > Thanks
> > > Pallav Singh

>
> > Neither - a simple template class eliminates the issue altogether:

>
> > <code>

>
> > #include <stdexcept>

>
> > template < typename Type >
> > class singleton
> > {
> > * * * * public:

>
> > * * * * singleton( void )
> > * * * * {
> > * * * * * * * * Type* ptr = static_cast< Type* >( this );
> > * * * * * * * * if( self )
> > * * * * * * * * {
> > * * * * * * * * /*
> > * * * * * * * * * * * * Or what have you...
> > * * * * * * * * */
> > * * * * * * * * * * * * throw std::runtime_error
> > * * * * * * * * * * * * (
> > * * * * * * * * * * * * * * * * "Error: attempt to instantiate multiple instances of a singleton"
> > * * * * * * * * * * * * );
> > * * * * * * * * }
> > * * * * * * * * self = ptr;
> > * * * * }

>
> > * * * * static inline Type& instance( void )
> > * * * * {
> > * * * * * * * * return *self;
> > * * * * }

>
> > * * * * static inline bool exists( void )
> > * * * * {
> > * * * * * * * * return self != 0;
> > * * * * }

>
> > * * * * virtual ~singleton( void )
> > * * * * {
> > * * * * * * * * self = 0;
> > * * * * }

>
> > * * * * private:

>
> > * * * * singleton( singleton const& );

>
> > * * * * singleton& operator = ( singleton const& );

>
> > * * * * static Type* self;

>
> > };

>
> > template < typename Type >
> > Type* singleton< Type >::self = 0;

>
> > // Example:

>
> > #include <iostream>

>
> > class foo : public singleton< foo >
> > {
> > * * * * public:

>
> > * * * * void bar( void ) const
> > * * * * {
> > * * * * * * * * std::cout << "foo::bar( )" << std::endl;
> > * * * * }

>
> > };

>
> > int main( void )
> > {
> > * * * * try
> > * * * * {
> > * * * * * * * * foo a;
> > * * * * * * * * foo::instance( ).bar( );
> > * * * * * * * * foo c; // Whoops!
> > * * * * * * * * foo::instance( ).bar( );
> > * * * * }
> > * * * * catch( std::exception const& error )
> > * * * * {
> > * * * * * * * * std::cerr << error.what( ) << std::endl;
> > * * * * }

>
> > }

>
> > </code>

>
> > The beauty of the design is that it allows the user to decide how to
> > allocate and initialize the derived class; it's sole purpose is to
> > make sure that multiple instances aren't created. Best of all, it's
> > completely generic!

>
> > Cheers.

>
> Looks as beautiful like any other reinvented square wheel. The
> requirements seem to be that such code must work:
>
> *int main( void )
> *{
> * * *{
> * * * * *foo a;
> * * * * *foo::instance( ).bar( );
> * * *}
> * * *foo c; // Second singleton and *NO* Whoops
> * * *foo::instance( ).bar( );
> *}
>
> Not sure why someone needs to have global state? Typical example of
> singletons is a logger. Huh? So ... OK. What if i need to have
> separate logs from different modules? I will then need new class for
> each log to have separate singleton logger for each module? Nonsense.
>
> What if i need to have separate logs from different threads? Then that
> Logger::instance() should give me "different" singletons based on
> thread ID? Huh? Why it can't just be debugging::log() and where it
> logs is its internal business, no global state no nothing?
>
> As for your code ... same thing with 10-12 lines instead of 70-80:
>
> *#include <iostream>
> *namespace foo
> *{
> * * *void bar()
> * * *{
> * * * * *std::cout << "foo::bar()" << std::endl;
> * * *}
> *}
>
> *int main()
> *{
> * * *foo::bar();
> *}
>
> Things that contain nothing are not worth allocating or initializing.


So...your point is that you hate the singleton pattern? Got it. I hate
it when people post snarky comments for no apparent reason,
personally. To each his (and her) own, I guess.

Cheers.
 
Reply With Quote
 
Pallav singh
Guest
Posts: n/a
 
      07-05-2010
On Jul 5, 7:48*am, sebastian <(E-Mail Removed)> wrote:
> On Jul 4, 6:31*pm, Öö Tiib <(E-Mail Removed)> wrote:
>
>
>
> > On 4 juuli, 23:58, sebastian <(E-Mail Removed)> wrote:

>
> > > On Jul 4, 9:02*am, Pallav singh <(E-Mail Removed)> wrote:

>
> > > > Hi

>
> > > > what the consideration parameter to choose stateless and statefull
> > > > Singleton ?

>
> > > > Thanks
> > > > Pallav Singh

>
> > > Neither - a simple template class eliminates the issue altogether:

>
> > > <code>

>
> > > #include <stdexcept>

>
> > > template < typename Type >
> > > class singleton
> > > {
> > > * * * * public:

>
> > > * * * * singleton( void )
> > > * * * * {
> > > * * * * * * * * Type* ptr = static_cast< Type* >( this );
> > > * * * * * * * * if( self )
> > > * * * * * * * * {
> > > * * * * * * * * /*
> > > * * * * * * * * * * * * Or what have you...
> > > * * * * * * * * */
> > > * * * * * * * * * * * * throw std::runtime_error
> > > * * * * * * * * * * * * (
> > > * * * * * * * * * * * * * * * * "Error: attempt to instantiate multiple instances of a singleton"
> > > * * * * * * * * * * * * );
> > > * * * * * * * * }
> > > * * * * * * * * self = ptr;
> > > * * * * }

>
> > > * * * * static inline Type& instance( void )
> > > * * * * {
> > > * * * * * * * * return *self;
> > > * * * * }

>
> > > * * * * static inline bool exists( void )
> > > * * * * {
> > > * * * * * * * * return self != 0;
> > > * * * * }

>
> > > * * * * virtual ~singleton( void )
> > > * * * * {
> > > * * * * * * * * self = 0;
> > > * * * * }

>
> > > * * * * private:

>
> > > * * * * singleton( singleton const& );

>
> > > * * * * singleton& operator = ( singleton const& );

>
> > > * * * * static Type* self;

>
> > > };

>
> > > template < typename Type >
> > > Type* singleton< Type >::self = 0;

>
> > > // Example:

>
> > > #include <iostream>

>
> > > class foo : public singleton< foo >
> > > {
> > > * * * * public:

>
> > > * * * * void bar( void ) const
> > > * * * * {
> > > * * * * * * * * std::cout << "foo::bar( )" << std::endl;
> > > * * * * }

>
> > > };

>
> > > int main( void )
> > > {
> > > * * * * try
> > > * * * * {
> > > * * * * * * * * foo a;
> > > * * * * * * * * foo::instance( ).bar( );
> > > * * * * * * * * foo c; // Whoops!
> > > * * * * * * * * foo::instance( ).bar( );
> > > * * * * }
> > > * * * * catch( std::exception const& error )
> > > * * * * {
> > > * * * * * * * * std::cerr << error.what( ) << std::endl;
> > > * * * * }

>
> > > }

>
> > > </code>

>
> > > The beauty of the design is that it allows the user to decide how to
> > > allocate and initialize the derived class; it's sole purpose is to
> > > make sure that multiple instances aren't created. Best of all, it's
> > > completely generic!

>
> > > Cheers.

>
> > Looks as beautiful like any other reinvented square wheel. The
> > requirements seem to be that such code must work:

>
> > *int main( void )
> > *{
> > * * *{
> > * * * * *foo a;
> > * * * * *foo::instance( ).bar( );
> > * * *}
> > * * *foo c; // Second singleton and *NO* Whoops
> > * * *foo::instance( ).bar( );
> > *}

>
> > Not sure why someone needs to have global state? Typical example of
> > singletons is a logger. Huh? So ... OK. What if i need to have
> > separate logs from different modules? I will then need new class for
> > each log to have separate singleton logger for each module? Nonsense.

>
> > What if i need to have separate logs from different threads? Then that
> > Logger::instance() should give me "different" singletons based on
> > thread ID? Huh? Why it can't just be debugging::log() and where it
> > logs is its internal business, no global state no nothing?

>
> > As for your code ... same thing with 10-12 lines instead of 70-80:

>
> > *#include <iostream>
> > *namespace foo
> > *{
> > * * *void bar()
> > * * *{
> > * * * * *std::cout << "foo::bar()" << std::endl;
> > * * *}
> > *}

>
> > *int main()
> > *{
> > * * *foo::bar();
> > *}

>
> > Things that contain nothing are not worth allocating or initializing.

>
> So...your point is that you hate the singleton pattern? Got it. I hate
> it when people post snarky comments for no apparent reason,
> personally. To each his (and her) own, I guess.
>
> Cheers.


++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++
+++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++
+++++++++

Hi

Q How does Polymorphism get implemented in Singleton ?
Q can we modify basic Singleton in such a way that all the class that
Inherit it become Singleton ?

Thanks
Pallav
 
Reply With Quote
 
Öö Tiib
Guest
Posts: n/a
 
      07-05-2010
On 5 juuli, 05:48, sebastian <(E-Mail Removed)> wrote:
> On Jul 4, 6:31*pm, Öö Tiib <(E-Mail Removed)> wrote:
>
>
>
> > On 4 juuli, 23:58, sebastian <(E-Mail Removed)> wrote:

>
> > > On Jul 4, 9:02*am, Pallav singh <(E-Mail Removed)> wrote:

>
> > > > Hi

>
> > > > what the consideration parameter to choose stateless and statefull
> > > > Singleton ?

>
> > > > Thanks
> > > > Pallav Singh

>
> > > Neither - a simple template class eliminates the issue altogether:

>
> > > <code>

>
> > > #include <stdexcept>

>
> > > template < typename Type >
> > > class singleton
> > > {
> > > * * * * public:

>
> > > * * * * singleton( void )
> > > * * * * {
> > > * * * * * * * * Type* ptr = static_cast< Type* >( this );
> > > * * * * * * * * if( self )
> > > * * * * * * * * {
> > > * * * * * * * * /*
> > > * * * * * * * * * * * * Or what have you...
> > > * * * * * * * * */
> > > * * * * * * * * * * * * throw std::runtime_error
> > > * * * * * * * * * * * * (
> > > * * * * * * * * * * * * * * * * "Error: attempt to instantiate multiple instances of a singleton"
> > > * * * * * * * * * * * * );
> > > * * * * * * * * }
> > > * * * * * * * * self = ptr;
> > > * * * * }

>
> > > * * * * static inline Type& instance( void )
> > > * * * * {
> > > * * * * * * * * return *self;
> > > * * * * }

>
> > > * * * * static inline bool exists( void )
> > > * * * * {
> > > * * * * * * * * return self != 0;
> > > * * * * }

>
> > > * * * * virtual ~singleton( void )
> > > * * * * {
> > > * * * * * * * * self = 0;
> > > * * * * }

>
> > > * * * * private:

>
> > > * * * * singleton( singleton const& );

>
> > > * * * * singleton& operator = ( singleton const& );

>
> > > * * * * static Type* self;

>
> > > };

>
> > > template < typename Type >
> > > Type* singleton< Type >::self = 0;

>
> > > // Example:

>
> > > #include <iostream>

>
> > > class foo : public singleton< foo >
> > > {
> > > * * * * public:

>
> > > * * * * void bar( void ) const
> > > * * * * {
> > > * * * * * * * * std::cout << "foo::bar( )" << std::endl;
> > > * * * * }

>
> > > };

>
> > > int main( void )
> > > {
> > > * * * * try
> > > * * * * {
> > > * * * * * * * * foo a;
> > > * * * * * * * * foo::instance( ).bar( );
> > > * * * * * * * * foo c; // Whoops!
> > > * * * * * * * * foo::instance( ).bar( );
> > > * * * * }
> > > * * * * catch( std::exception const& error )
> > > * * * * {
> > > * * * * * * * * std::cerr << error.what( ) << std::endl;
> > > * * * * }

>
> > > }

>
> > > </code>

>
> > > The beauty of the design is that it allows the user to decide how to
> > > allocate and initialize the derived class; it's sole purpose is to
> > > make sure that multiple instances aren't created. Best of all, it's
> > > completely generic!

>
> > > Cheers.

>
> > Looks as beautiful like any other reinvented square wheel. The
> > requirements seem to be that such code must work:

>
> > *int main( void )
> > *{
> > * * *{
> > * * * * *foo a;
> > * * * * *foo::instance( ).bar( );
> > * * *}
> > * * *foo c; // Second singleton and *NO* Whoops
> > * * *foo::instance( ).bar( );
> > *}

>
> > Not sure why someone needs to have global state? Typical example of
> > singletons is a logger. Huh? So ... OK. What if i need to have
> > separate logs from different modules? I will then need new class for
> > each log to have separate singleton logger for each module? Nonsense.

>
> > What if i need to have separate logs from different threads? Then that
> > Logger::instance() should give me "different" singletons based on
> > thread ID? Huh? Why it can't just be debugging::log() and where it
> > logs is its internal business, no global state no nothing?

>
> > As for your code ... same thing with 10-12 lines instead of 70-80:

>
> > *#include <iostream>
> > *namespace foo
> > *{
> > * * *void bar()
> > * * *{
> > * * * * *std::cout << "foo::bar()" << std::endl;
> > * * *}
> > *}

>
> > *int main()
> > *{
> > * * *foo::bar();
> > *}

>
> > Things that contain nothing are not worth allocating or initializing.

>
> So...your point is that you hate the singleton pattern? Got it. I hate
> it when people post snarky comments for no apparent reason,
> personally. To each his (and her) own, I guess.


Did i really insult you somewhere? Sorry then. I thought i posted
reasons. I do not dislike something blindly. I have met them more than
anyone deserves, and i have learned all possible and impossible ways
how to deal with them. One-size-fits-all solutions are usually wrong
so don't be insulted if yours is not exception.

Why the problem with singletons is not so apparent? What is the
difference between calling "globalVariable.doSomething()" and
"SingletonClass::instance().doSomething()" (other than some extra
letters to type on second case)? Both are tight coupling with global
state only semantics are different. Sometimes it is not worth to avoid
tight coupling between close classes but singleton is far and global.

The problem is not only tight coupling between distant things but that
such coupling is hidden within code (call site).

One often named purpose of singletons is that these limit the count of
how many instances there may be simultaneously (1 on case of
singleton). That sounds like responsibility of owners of objects to
limit number of simultaneous instances. Oh yes, global state does not
have owners, it is self-owned.

Also why only one instance? Who knows. "Pragmatic" reasons like "There
was only one window/database/display/player/client/user/account/store/
harddrive/configuration when we started with that application, so we
decided to carve it into rock in most hard way to modify." Mono-media.

Finally massive dependency on global state makes it impossible to rely
on unit tests. I can not imagine large project without even larger
amount of unit tests. Global state carries on behind scenes and so
unit tests may pass (or fail) just because of order in what these were
ran.

These are not apparent reasons? Imagine 25 man-years that was put into
C++ project. Result was with half of classes singletons (with
similarly various "solutions" and "purposes" and "pragmatic reasons").
Someone was paying lot of money for these 25 man-years so it was
like ... desirable thing for him. Original global-state-lover
architects did run far away because quite non-ambitious and reasonable
change requests are near-impossible to fulfill. How to explain why
what he has now is so costly to extend or maintain?

So ... nothing personal, sebastian, but yes i dislike singletons. For
good reasons.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: StateFull vs Stateless Singleton sebastian C++ 1 07-05-2010 04:12 PM
a statefull ejb doesn't get the timeout. Tiwkiz Java 1 01-11-2007 11:01 PM
Dadatabsae Connection problem with Statefull Sessoin Bean design Java 1 01-10-2007 02:24 AM
timeout problem with statefull session bean Nathac Java 0 12-22-2006 11:34 AM
Static Method/stateless/statefull/how to :-) MaxMax C++ 4 10-25-2005 08:10 AM



Advertisments