> > > <vendor>
> > > The jBoss EJB container allows one to use stateless
> session beans for
> > > this. A special instance pool which guarantees that only
> one instance of
> > > the bean is created can be used for exactly this purpose.
> This allows
> > > one to do singletons as an EJB, which brings all the
> other benefits of
> > > EJB, and also helps keep the application EJB only.
> > > </vendor>
> >
> > Does the server single-thread access to the instance in
> this case, in case the
> > instances are not thread-safe?
>
> <vendor>
> Yes. The EJB semantics are preserved. It behaves the same way as an
> ordinary stateless session bean, but with the addition that the pool
> only contain at most one instance which is synchronized.
> </vendor>
>
> It's perhaps not a perfect solution (although I can't think
> of any cons
> right now), but should be good enough for most situations.
>
> /Rickard
>
I agree, best that the EJB spec allows, as flawed as this is.
I see the problem with this design is; performance (lack of).
Serialized calls to a singleton is ... not acceptable. How can this
be so easily over looked and shrugged off??? Maybe because there's
so many short commings that how can we get upset over just the Singleton
problem?
Maybe I'm the only one who feels the Emperor's cloths are not as
fine as the EJB acedemians describe.
:) LOL
curt
Curt Smith
Z-Tel
email: [EMAIL PROTECTED]
work: 404-237-1166 x182
FAX: 404-237-1167
===========================================================================
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".
