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?
> 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. 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 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. 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".
