hi all ,

im just trying to figure out something,
where or how is the use of singletones in enterprise application effective? ,

every object in an enterprise app must be scalable right?
exactly where would using singletones will be an advantage that wont hurt scalability?

I am not such a big fan of using singletons in J2EE. Yes, if singletons manage resource access, they do become a scalability issue. We also have to consider a fact that then it becomes a Per JVM singleton unless we coded otherwise.

If you have noticed, the industry favor of singleton has dwindled over the years. It was even debated in the recent OOPSLA if it has to be removed from the GoF. And also, notice that there is no singleton pattern(or a variant) present in the Core J2EE patterns list.

A singleton is usually based on the "static" keyword, and in J2EE with multiple class loaders, it might not work exactly as we expect it to.

This is not to discount the use of singleton, just to be used as a guard against using it everywhere.

If we need caching, Singleton would be the appropriate choice. But as you mentioned, if singleton is not preferred in J2EE, what are the other ways available to implement caching?

And, how does singleton affect scalability? I don't get the point. Service Locator, one of the core J2EE pattern, is implemented using singleton.

first of all only the webapp serviceLocator is based as a singleton.

second imagine a situation where a singleton is managing datasource access for ejbs.

everytime an ejb wants to get a DS it has to call -

serviceLocator.getInstance().getDataSource() ;

right?

lets say our application has a busy day where 500 clients are using the system using a statefull session beans to keep their state. that mean that we have 500 ejbs trying to gain access from one singleton!!!
there goes scalability .....

the solution is to create it as a simple pojo and hold/cache it in the ejb itself by creating the serviceLocator in every create/activate and nulling him in passivate .
now every bean has its serviceLocator for his lifecycle.

now you will say i will use map to cache the dataSource in the serviceLocator so that it wont have to use lookup everytime - that will also cause a scalability issue though it depends in your application , and you also loose the hot deploy advantage :
lets say u want to switch databases the caching serviceLocator will not perform a lookup so u will have to restart your application !!

again its all depends in your application needs
but remember what is the big cost here ?
a littel object(serviceLocator) created for each bean ?

but if every stateful session bean has its own service locator, originally we have only one object to handle all service locate, but now we have 500 objects (assume all of them are active)

I wonder which method is better, is there any prove or benchmark showing the benifit of using many small objects than just one singleton?

Regards

i think , that its prefered to use the serviceLocator as a pojo and use other factories as singletones like ejbHomeFactory etc.

take a look at java blueprints's patterns :

they have 2 versions of the serviceLocator
a webApp one which is a singleton caching services in a map
and an ejb one , with a public contructor without caching

(though it has a static field type ServiceLocator that is never used - odd).

a friend of mine wrote an application that holds a counter for serviceLocator creation (as singleton) and every time its counter counts a 100 requests it creates a new ServiceLocator . ...

regards

thank u ....