Tim Fox wrote:
> Randy Stafford wrote:
>
> > > 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!)
>
[Randy Stafford] No, I'm not recommending "service based objects",
which I'm interpreting as objects without intrinsic identity or instance
variables that load/store their state every business method. I saw how MTS
does that, passing an oid into every method, and I was disgusted - it
basically reduces OOPLs to a fancy way or organizing subroutine libraries.
Entity beans are a little better in that they appear to have intrinsic
identity and permanent instance variable values, even if tricks are done
behind the scenes to maintain that illusion (e.g., load/store, instance
swapping, etc.). But IMHO entity beans are the current embodiment of some
questionable ideas (that business objects should be remotable and
responsible for their own persistence) that have been around for a long time
- the idea of entity beans actually has a long heritage within IBM (read
Roger Sessions' book Object Persistence sometime), and Sun people
acknowledge this heritage. Plain old java objects and OODBMSes facilitate a
much more elegant implementation of a domain model.
And you're right, there is a fundamental tension between
load-balancing over multiple VMs (each of which can have its own
instantiation of a persistent business object), and caching the state of
that business object in-memory. GemStone's architecture was designed to
resolve this tension 15 years ago, and currently does so in a scalable,
performant manner.
> > 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?
>
[Randy Stafford] Ah. There are two parts to the problem here. If
the in-memory state of an object changes during a use case, it is pretty
easy to flush the in-memory state to an RDBMS without requiring entity beans
- it is easy to write a framework to do so, assuming you apply the patterns
of service-based architecture (by which I mean a layered architecture
featuring a "services" layer between the application and domain layers),
short transactions, and service-controlled transactions. The other part of
the problem is the scenario where the RDBMS can change out from under the
cache as a result of some other application updating the RDBMS. If this
scenario exists, it represents a harder problem that must be designed for.
You have to know when to invalidate your cache. In general the only
mechanisms available are polling or trigger-based callouts, but the problem
has more to do with semantics than mechanisms. You have more potential
concurrency conflict, which you have to detect and deal with at the
application level. The easy way out is to not cache, which probably hurts
performance otherwise why would you cache, and you still probably have to
detect concurrency conflicts at the application level before writing the
RDBMS. Note that this whole set of issues is recognized, in that some EJB
containers contain an optimization where they'll skip some ejbLoad
invocations if you tell them that they "own" the underlying database.
> > 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.
>
[Randy Stafford] Enen though we support both configurations, our
customers tend to run their apps on one bigger machine as opposed to an
array of smaller ones, because our architecture uses shared memory between
JVMs in state synchronization, and of course there is a cost associated with
moving these memory pages between hosts. We have one customer doing about
2M business transactions per day through our server, and its host
(admittedly, a beefy Sun enterprise server) was only running at about 20% at
last report. You could use an array of smaller machines, but you'd pay an
initial response time penalty warming up the shared page cache on each
machine.
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".
