As I said, I haven't actually tried any other vendor's implementation of
distributed state. I was just pointing out that this is a very, very hard
problem to solve.
Read only is trivially easy to solve. Read mostly is solvable as well. True
read/write is very hard to solve, especially with atomic synchrony requirements
(i.e. every participant sees the same ordering of events). Relaxing the atomic
requirement makes things easier and is (imho) the only way something like this
will truly scale. Adding the requirement of fault tolerance to this mix makes
things all that much more difficult.
My point is that people writing applications which use the singleton pattern
don't always comprehend what kind of a tar pit they are stepping into.
Application developers should understand that there is no portable, vendor
independent way of doing this. Applications that absolutely depend on
singletons should make sure they examine what support the vendor can supply,
and realize they are almost certainly locking themselves into a particular
vendor.
There is no magic bullet here, and as you at Gemstone know, this kind of thing
is hard to implement and make scale.
> 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".
>
>
===========================================================================
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".
