Now, now. We can't say someone is an idiot without saying why.
Referring to http://www.objectwatch.com/issue18.htm
In his model, the application server is defined by MTS (in Microsoft's
world) or EJB (in Java's world). This is a fundamental error, as EJB is
something an application server *runs*, not that which *defines* and
application server.
Every single person on earth pools database connections. Anyone who
doesn't is either building a toy, a test bed, or has a VM like ours.
That being said, the fundamental premise of his article is just plain
wrong.
Once you get past the erroneous statement about connection pools, his
basic claim is that "because MTS is stateless", it is superior. EJB has
stateless models as well as stateful models. He somehow believes that
only stateless server models can have database connection pools - wrong.
Stateless application server models are essentially stored procedures
that operate on the database state. There is no state that is kept
between calls on the stored procedure, so you can just throw everything
away, and start off "like a virgin" with the next call (apologies to
Madonna).
This is an extremely old model that has served extremely well. This is
why every database in the world has some sort of stored procedure
language that runs right in the sql process and is tuned for database
operations, and is good about transient state between calls (i.e., the
database call is a central part of the memory management).
In the client/server model, the application moved from the database
server onto the client. This was great, as all the wisiwyg interface
enabled applications required enormous bandwidth between the domain
model and the graphical user interface.
The era of MVC (model view controller) was born, and client side
programs sometimes swelled to elephantine proportions (up to 4 Meg, if
it was written in Smalltalk <g>). Today, these sizes are trivial (Most
browsers require upwards of 20 meg with all the crap happening).
The main problem with client-server was the client talking to the
server. It's slow moving all that data between the database and the
client machine.
This was alleviated somewhat by TP monitors and such, running code on
behalf of the client, but the interfaces weren't really OO.
Now we have middle tier application servers which do much the same thing
that a TP monitor had to do - pool database connections, batch server
requests, run code, deal with security. Serve a bunch of clients.
However, the code that is running in the app server is the client side
of the client-server application, minus the user interface.
The problem is, these applications need transient state. Don't get me
wrong. There's a LOT of client-server applications that can use a
stateless server model. The application STILL has transient state, it's
just that the transient state is all on the client side. The interface
to the application is one where the state of the server side of the
application is stored in the database, not in memory.
It's a great model. It's transactional in state (i.e., the application
state can be committed, rolled back, and is serialized between clients).
But it's slowwww. The very qualities one likes about it have a price
that is several orders of magnitude slower than state that is only in
the memory, isn't committed to disk, doesn't survive server crash.
Transient application state is damn useful. If we didn't need state we
would all be programming in ML, not Java. Even HTTP had to use cookies
to provide state to the so-called "stateless" world of web servers.
So, EJB provides a server application model that has transient state as
a FEATURE. This differentiates it from MTS, who's only server
application model is STATELESS.
In EJB, the server application can keep transient state between calls on
the server from the client. EJB also has a stateless application model
which makes it equivalent to MTS' server application model.
Transient state in a server application is non-trivial for an
application server to implement. Which is why, I suspect, Microsoft
doesn't support it. (just had to kick a chained dog <g>)
Transient state is hard because memory is a precious resource that has
to be managed. If you don't have garbage collection, the APPLICATION
programmers have to manage the resource themselves.
Letting application programmers manage a resource is like letting a
bunch of credit card companies set interest rates. Everyone ends up
getting gouged.
When someone mis-manages memory, you usually get a core dump in the
process, and life is not good. Overwriting memory, dangling pointers -
all demons that require automatic memory management to slay (i.e.
garbage collection).
C++ does have conservative garbage collectors available, but
conservative gc is sloppy (that's why it's conservative).
The MTS model is, of course, stateless, so it's garbage collection
strategy is to throw out everything at the end of a call.
Don't get me wrong - this works. It's fast and it scales really well.
However, it still leaves all the transient state in the client, still
requiring a fat client. Stateless interactions with the server impose a
very limited vocabulary on the interaction between the client and the
server.
EJB takes the stateless model and provides transient state that survives
calls. When a client talks to an EJB, the EJB will still remember stuff
when the client sends it the next message.
This is darn useful. ALL applications need transient state - unless
they're really brain dead or use the database as state.
The question really is whether the transient state is on the client or
the server.
Microsoft, of course, would like you to keep it on the client, where
they control the market. Sun, of course has the opposite view.
But this business about EJB not providing database connection pools is
COMPLETELY insane. I can't believe he said that.
Mark Hapner wrote:
>
> Let me say publicly that the author of this article may know something about COM
> (I'm not an expert on that subject so I will let others judge his competence);
> however, I am an expert on EJB and he knows practically nothing about the
> technology. The errors in this article are to numerous to mention. Please
> completely disregard it and get your information from a more reliable source.
>
> [EMAIL PROTECTED] wrote:
>
> > > Now I'm using WebLogic, whose EJB support, as I understand it, is supposed
> > > to offer me a more open way of accessing these kind of services. But I
> > > don't see where EJB addresses any of these questions.
> >
> > There is a good article out there that explains
> > the concepts of EJB with respect to scalability.
> > You find it here: http://www.objectwatch.com/issue18.htm
> > (ObjectWatch Newsletter 18 - In the Fishbowl; Scalability in EJB and MTS)
> >
> > To summarize its main points:
> >
> > - The spec. doesn't define any specific mechanism for pooling and
> > db connection reuse
> > (in fact Weblogic and others do a lot of fancy things on that...)
> >
> > - But: EJB does not use a Just-In-Time-Activation algorithm for
> > instance management; instead it uses another instance management
> > algorithm called Instance Pooling.
> > (the middle tier instances - session or entity beans -
> > are themselves pooled, not the db conn.)
> >
> > With regards,
> > Martin
Hal
___
Casual match in a very dry field
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".
