Non-EJB distributed architecture ???

Discussions

EJB design: Non-EJB distributed architecture ???

  1. Non-EJB distributed architecture ??? (3 messages)

    Hi all,

    I have been working with EJBs for a while, but with my latest project it seems EJB is not the solution. See details below:


    -Shared data is continually updating
    -At any given time *many* gigs of persistent data will be in memory
    -State must be shared amongst *many* clients (the reason I can't use EJB)

    Given the above I cannot (for performance reasons) use the DB as the exclusive means of sharing state/data amongst many clients. Thus, unless I am mistaken, this rules out EJB as an option. If this is the case, is there any AppServer/architecture which allows for an application to be load balanced, distributed across multiple machines, and written as if it was running on a single VM???

    Basically, I need an EJB system without the "assume you're making a web app" EJB restrictions.

    Any suggestions??

    Thanks,
    JC

    P.S. I guess it would be alot simpler if I just told you I'm trying to make the back end for a persistent-world game like Everquest or Asheron's Call.

  2. Have you looked at GemStone? They have a persistent cache architecture that I've heard performs really well. Just a thought.

    --
    Tinou
    www.tinou.com
  3. Try Sybase EAServer (Jaguar)
    It's supports *shared* CORBA components (and EJB too) created with C, C++, Java, PowerBuilder, ActiveX.
    The *shared* components allow sharing state/data amongst many clients.
    Jaguar allows for an application to be load balanced, distributed across multiple machines etc.
  4. <quote>-State must be shared amongst *many* clients (the reason I can't use EJB)</quote>

    Isn't the idea of entity beans for sharing data among multiple clients, with TX stuff taken care of for you by the container? Isn't it supposed to be a every scalable solution? Did you hit performance limit of EJB (because of the container incurred overhead)? Sounds like your system is like a real-time system (data constantly changing, like stock market data feed), and some kind of messaging system may be a better solution.