Seth,
I am not sure if you would need to enforce singleton type on design pattern
when it comes to EJB. From what I know, the container will allocate and
manage the pool of beans and decide on the number of beans instances
depending on the traffic. As such, the bean developers should not have to
worry about about concurrency control and threading issues. These issues
should now be handled by the EJB container.
Based on this premise, I do not understand why some ppl are looking to
implement the singleton pattern. Please enlighten me if I am missing
anything here.
Thanks.
-Sunil .K
----- Original Message -----
From: Seth Hawthorne <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 31, 2000 12:32 AM
Subject: Singleton design/implementation techniques
> We have worked with C++ for the past 5 years, but are new to EJB
design/implementation. One of our biggest challenges is knowing when to map
C++ design paradigms that we are familiar with (signeltons, polymorpism,
...etc) to EJBs and knowing when we should be thinking in terms of different
paradigms.
>
> For instance, there are a number of places in our design where we have
"manager" objects that encapsulate a collection of objects from which they
select an object to delegate work to. Such "manager" objects are logically
singeltons, however, EJBs seem not to provide a direct representation for
singeltons. This leads to a number of related questions:
>
> 1) Is this design approach reasonable? Are there any EJB patterns that
might apply?
>
> 2) We have seen several approaches to implementing singletons mentioned in
this newsgroup. The first is creating an object bound using JNDI, and the
second is creating an object with a static accessor. Which approach is
generally preferred? What are the pros and cons?
> Does using a JNDI based object pose the risk of a single point of failure
or scaling problems?
>
> 3) When should the singleton objects be created and initialized? Should
this always be done on server startup?
>
> Any and all input is greatly appreciated. Thanks!
>
> Seth Hawthorne
> OpenGrid
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
