• 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
  • Ron McLeod
  • Junilu Lacar
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • Carey Brown
  • Stephan van Hulst
Bartenders:
  • Frits Walraven
  • fred rosenberger
  • salvin francis

Business Delegate

 
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello

I have seen that many developpers implement Business Delegate as singleton.. What about concurrent access and thread safety ?

Thanks
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If you decide to cache handles for session facades, a Singleton may be better. But you are right, you might run into synchronzation problems if the cache is read-write. I personally don't see added adavantages in making them a Singleton. What about others? Any comments?
 
samou Mouloud
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with this implementation only if there is a one-to-one relationship with a session facade.

Mouloud
SCJP, SCWCD, ICED, SCEA part I
 
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ajith Kallambella:
I personally don't see added adavantages in making them a Singleton. What about others? Any comments?



Agree with you. Why Singleton ??
The EJB Container is supposed to allow concurrent accesses thru multi instances of an EJB. If the Business Delegate is a Singleton, then you loose this possibility. Why would you want to have a thread-safe session facade ?

Others, any opinion ???
 
samou Mouloud
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
By one-to-one relationship, I don't mean one instance to one instance. You may cache a reference to the session bean's HomeHandle (not a reference to a Handle)
Mouloud
 
Ajith Kallambella
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by samou Mouloud:
By one-to-one relationship, I don't mean one instance to one instance. You may cache a reference to the session bean's HomeHandle (not a reference to a Handle)
Mouloud



Sure one can do that, but (here's my favourite quote) is the juice worth the squeeze? - I think the drawbacks of singleton, stale references and having to synchronize multiple access outweigh the benefits of not having to lookup a reference every time. So, I ask here - give me one more reason why should I use a Singleton
 
samou Mouloud
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ajith

I agree with you. This pure theory, I don't see any real benefit with a singleton Business Delegate.
Mouloud
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Whoa! Isn't the business delegate just supposed to provide a view of the business functions / services to the client and the lookup / cache to be handled by the service locator. So why mix the two into the delegate?
 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is right. Normally the Service Locator is supposed to do the JNDI lookup and create/save the handler, and it is wise to implement as a Singlton, not the business delegate though.
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The following are excerpts from the J2EE Design Patterns book published by O'reilly:

Business delegates can be staeful or stateless. To use a stateful business delegate, generate an instance of the business delegate class. To create a stateless business delegate, declare the business delegate methods as static.

...

Here's a rule of thumb: if a business delegate requires a resource that is both expensive to create and that must be created specifically for the current user (such as a JAAS security principal), and if that resource will be used multiple times within the same delegate by the same thread, use a stateful delegate. You should also use a stateful delegate if the delegate needs complex configuration specifically for the current invocation, rather than trying to pass in all configuration information with each method call. Otherwise, look for opportunities to use a stateless delegate.
 
What are your superhero powers? Go ahead and try them on this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic