>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.
I hate to pick holes in your analogy but surely you wouldn't need a bridge
if there were no gravity. ;-)
WIth regards to Singletons...there have been a number of lively debates
on the list with some nice ideas put forward. You can find them by
searching the archives at archives.java.sun.com
regards
Duncan Alexander
Victor Chandler International
-----Original Message-----
From: Shehrawat, Rishi [mailto:[EMAIL PROTECTED]]
Sent: 15 February 2000 06:18
To: [EMAIL PROTECTED]
Subject: Re: [EJB-INT] Singleton EJB's?
in case you are using weblogic it provides a facility of workpaces, which is
a memory area where objects can be stored...
you can create a named worspaces which can be there across multiple client
sessions.. you can also have monitors on the workspaces for updates,
removes.. etc. i guess this should solve your problem...
> > 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".
