Hal,
<vendor>
I respect your position. Yes, distributed shared memory is very hard, but we
have been solving this problem for many years.
We can implement singleton as a shared object very easily in our Persistent
Cache Architecture (PCA). Access to the PCA object can be wrapped in a bean
to provide an EJB based usage model. In this case there are multiple
physical instantiations of the singleton, but they are all kept in synch. It
depends very much how read vs. write intense the data behind the singleton
is. If it is read intense, the cache synchronization issue you refer to is
more challenging.
We can also implement singleton as a shared CORBA object activation. In this
case there is a single physical activation of the object.
So, we provide a couple ways to attack this problem, and depending on your
requirements one or the other will work better.
</vendor>
Regards,
-Chris.
> -----Original Message-----
> From: Hal Hildebrand (Work) [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, February 14, 2000 1:37 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Singleton EJB's?
>
> ----- Original Message -----
> From: Robert Claeson <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, February 11, 2000 4:26 PM
> Subject: Singleton EJB's?
>
> > I've yet to come up with a good solution on this one myself, so I'm
> turning
> > it over to you now: what would be the best approach to implement the
> > equivialent of a singleton EJB - i.e. one that contains shared data for
> all
> > sessions WITHOUT going through a database. I'm looking for something
> like a
> > singleton stateful session bean. A typical example would be a community
> web
> > site with two or more web servers working against an application server,
> > where it would be beneficial to keep shared data in memory on the app
> > server, i.e. things like the current number of users and the like.
>
> Distributed shared memory is a *really* hard problem. The singleton
> pattern
> works fine for small numbers of users but *never* scales. This is
> implicit in
> the notion of a singleton (single point of contention, after all). There
> are
> some companies who claim to perform magic and transparently replicate
> read/write singleton state across multiple machines. I haven't tried
> their
> stuff, so I can't say if they have succeeded. However, I'm skeptical of
> any
> solutions here because I know what these solutions would require (unless
> someone has figured out far more clever ways than I'm aware of - always a
> possibility).
>
> This issue is much like the problem of Gravity.
>
> You can build a terrific bridge if you don't have to deal with gravity.
> It
> makes the design so much cleaner, easier to maintain and understand.
>
> However, it doesn't work in real life, and unfortunately that is where it
> has
> to work.
>
> Dealing with distributed state from the beginning of the application will
> prevent the phenomenon where your demo's work great but do not scale
> beyond 10
> users.
>
> This is why building scalable applications is hard work. If it was as
> easy as
> just making an Entity bean, everyone would have done it already.
> Databases are
> there for really, really, really good reasons.
>
> Hal
> __
> What are we going to do tonight, Brain?
> Same thing we do every night, Pinky. Try to take over the world.
> http://www.hellblazer.com
>
> ==========================================================================
> =
> 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".
