• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Does service locator needs to be a Singleton to cache

 
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All

I was going through Sun BluePrints where they show 2 types of service locators

quoting from the blue prints
***************************************
The Java Pet Store sample application, v1.3.1 has two service locators: a Web-tier class ServiceLocator , and an Enterprise JavaBeansTM (EJB) tier class, also called ServiceLocator . Both classes manage lookup and caching of enterprise bean home interfaces, JMS and database connection factories, and environment entries within their respective tiers. The only difference between them is that the Web-tier class is a singleton, and it caches the objects it looks up. The EJB-tier class is not a singleton, and does not cache.
****************************************
Here are the links to the code piece

1) the 1 that looks up as well as caches
http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servicelocator/web/ServiceLocator.java.html

This is synchronized. My question is does it have to be that way. In the above code for caching was Singleton necessary

2) the 2nd one looks up but does not cache and is neither a Singleton

http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servicelocator/ejb/ServiceLocator.java.html

Do post your viewpoints on the same

Rgrds
Manish
 
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In case the results are indeed cacheable and the lookup methods are expensive (as for example in EJB lookups) I would use the cacheable singleton approach.
In all other cases I would prefere DI/IOC .

./pope
 
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by manish ahuja:
Hi All

I was going through Sun BluePrints where they show 2 types of service locators

quoting from the blue prints
***************************************
The Java Pet Store sample application, v1.3.1 has two service locators: a Web-tier class ServiceLocator , and an Enterprise JavaBeansTM (EJB) tier class, also called ServiceLocator . Both classes manage lookup and caching of enterprise bean home interfaces, JMS and database connection factories, and environment entries within their respective tiers. The only difference between them is that the Web-tier class is a singleton, and it caches the objects it looks up. The EJB-tier class is not a singleton, and does not cache.
****************************************
Here are the links to the code piece

1) the 1 that looks up as well as caches
http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servicelocator/web/ServiceLocator.java.html

This is synchronized. My question is does it have to be that way. In the above code for caching was Singleton necessary

2) the 2nd one looks up but does not cache and is neither a Singleton

http://java.sun.com/blueprints/code/jps131/src/com/sun/j2ee/blueprints/servicelocator/ejb/ServiceLocator.java.html

Do post your viewpoints on the same

Rgrds
Manish



For the first option, it may be preferable to cache the handle rather than the object. Also, one thing to note is that singletons may be unpredictable in a clustered environment.
[ November 18, 2004: Message edited by: Aneesha Singh ]
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Aneesha & Ali

Thanks a lot for your prompt response. What I intended to ask from my post was Cant we have caching without resorting to Singleton
Say I use the caching part of the code mentioned in the original post in Scenario1 & force it on scenario2.

Wont I be able to still use caching

In short do we have to have singleton to enable caching or I can have caching even without being a Singleton class

Thanks Once again
Manish
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
However you desing the locator the cacheing tool is singleton (there are cluster caching mechanisms, but their usage is more complex).

./pope
 
Aneesha Singh
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by manish ahuja:
What I intended to ask from my post was Cant we have caching without resorting to Singleton
Say I use the caching part of the code mentioned in the original post in Scenario1 & force it on scenario2.

Wont I be able to still use caching

In short do we have to have singleton to enable caching or I can have caching even without being a Singleton class



Well!
The thing is that the reason for using a singleton is to provide a single cache. Otherwise you could have multiple instances of the caching class and that would kind of defeat the purpose.
Why dont you want to use a singleton ... is there any particular reason?
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ali

This one is just for the kick.

Talking about DI/IOC & the new EJB3.0 can we say we can do away with the Service locator & Singleton pattern approach totally as we no longer would be needing these lookups


Rgrds
Manish
 
manish ahuja
Ranch Hand
Posts: 312
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey Aneesha

Thnks a lot for ur response. No I dont hate Singletons. Actually I was just trying to get to a scenario where Singleton would be imperative.
The reason being in 1 of the OOPSLA article by Martin Fowler certain patterns were mentioned as would be scrapped & replaced by new ones.

Singleton was 1 of them & I was just trying to arrive at the benefits offered by these


Once again thanks a lot for your immediate replies

Bye
Manish
 
Alexandru Popescu
Ranch Hand
Posts: 995
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by manish ahuja:
Talking about DI/IOC & the new EJB3.0 can we say we can do away with the Service locator & Singleton pattern approach totally as we no longer would be needing these lookups[/QB]



Indeed. Marin Fowler has a very interesting article on this.

./pope
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Aneesha Singh:
The thing is that the reason for using a singleton is to provide a single cache. Otherwise you could have multiple instances of the caching class and that would kind of defeat the purpose.



Well, you *could*, but noone is forcing you to. That is, you can have only one instance without using the Singleton pattern.

See http://www.butunclebob.com/ArticleS.UncleBob.SingletonVsJustCreateOne
reply
    Bookmark Topic Watch Topic
  • New Topic