See comments below:
Randy Stafford wrote:
> Hi Tim, you wrote:
>
> > Yep - the idea is that we would want to have a "cluster" of containers
> > distributed across several machines so that we can cope with the possibly
> > large
> > amount of hits.
> >
> [Randy Stafford] Yabbut how many VMs per container?
>
> > As I mentioned in my previous email - we currently utilise a model2 (MVC)
> > architecture using servlets, jsp and "normal" javabeans.
> > We've also implemented a persistence layer that handles the CRUD methods
> > for the
> > beans and optimistic locking,
> >
> [Randy Stafford] So it sounds like your servlets invoke your
> persistence layer and get back business objects implemented as normal java
> beans. That's all cool.
>
> > Currently, since we don't really store any state (apart from sessions -
> > which we
> > is ok since requests in the same session always go to the same server)
> >
> [Randy Stafford] Will this always be the case? That a given
> HttpSession always goes to the same server? Are you worried about losing
> session state in the event of a servlet VM crash?
You're right - currently there's no session fault tolerance - it might be nice
to have that
>
>
> > we don't have any synchronisation problems - ie we instantiate the beans
> > from the db at every request.
> >
> > It would be nice for us not to have to instantiate the beans at every
> > request -
> >
> [Randy Stafford] It would probably improve your response times.
>
> > which I believed EJB would enable us to do by holding in memory caches of
> > beans.
> > However it now looks (as you have said in your <gemstone:vendor/> tag)
> > that this
> > is a vendor specific add-on and hence a problem for us as we want our
> > applications to remain portable.
> >
> [Randy Stafford] Well, choose your poison. It's the old trade-off
> between standardization and competition. Remember "standard" SQL? Remember
> Oracle-specific and Sybase-specific extensions? What's more important to
> you: scalable performance or vendor pluggability? No matter which container
> you use, your code will probably always be aware of some vendor-specific
> optimization, "dirty flags" being a primary example. GemStone gives you
> persistence, state-synchronizaton, and scalability options that the other
> containers don't, and those are valuable options.
>
> > It seems that although EJB allows in memory caches - this is pretty
> > useless when
> > you have more than one server since no synchronisation is performed
> > between them
> > according to the EJB spec.
> >
> [Randy Stafford] That depends on what assumptions you're making
> about what an "ejb server" is.
>
> > I'm interested in EJB but I've yet to be convinced that EJB *per se* can
> > actually add anything to our setup.
> >
> > Its seems to me that EJB simply would add distributed transactions (which
> > we
> > wouldn't use) and give us RMI interfaces to our business objects (which we
> > wouldn't need).
> >
> > Is this is a fair summary of the capabilities of EJB or am I missing
> > something
> > (and I guess I am ;-) ) ...
> >
> [Randy Stafford] No, it's fair. I'm with all that. Personally, I
> don't have much use for entity beans.
Ok, so are you recommending pure "service based objects" rather than storing
state and having to synchronize? - isn't this though the model I am currently
using (instantiating the business objects on every request, and no in memory
caching).
It seems to me that stateful models + load balancing just don't go together.
This seems to be the way a lot of architects are going (including Micros*** with
MTS!)
It just occurred to me that, with EJB, the clever people at Sun had come up with
some way of making Stateful models work - oh well... my hopes are dashed.
> I prefer to implement my business
> objects as plain old Java objects that are never exposed remotely - and
> there are other, less-expensive-than-entity-beans ways of sync'ing in-memory
> state with persistent state, especially with GemStone, but also with
> RDBMSes.
I'm interested to know how would you sync state using an RDBMS? Would this be
some kind of trigger that calls back into the containers and tells the objects
to reload?
> I think EJB adds value in a few areas. Session beans encourage
> service-based architecture with a short transaction model and
> service-controlled transactions, all of which are good things. But having
> said all that, I'm also not really a fan of distributed architectures for
> serving user interfaces, so I don't really need EJB for that purpose (you
> can apply the above patterns without EJB). I'd prefer to have all layers of
> my layered architecture running in the same VM, and then load-balance across
> an array of such VMs for scalability.
Would this be an array of VM's all running on the same machine? (Or is this not
an important distinction?)
I guess the advantage here would be a network call to synchonized state is more
expensive than an interprocess call between VMs.
Isn't there a problem with scalability though in having all your VMs on one
machine? Ie there's a limit to how powerful a machine you can buy but no limit
to how many machines you can buy.
> Especially with GemStone's PCA, this
> is much more efficient than serializing object state between processes.
>
> RPS
>
> ===========================================================================
> 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".
--
Tim Fox (��o)
Hyperlink interactive
http://hyperlink.com
email: [EMAIL PROTECTED]
phone: +44 (0) 207 240 8121
===========================================================================
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".
