Re: choices regarding where to place code - in the database or middletier

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 21 Jan 2004 09:39:05 -0600
Message-ID: <u65f5pb4q.fsf@standardandpoors.com>

On Tue, 20 Jan 2004, joeNOSPAM_at_bea.com wrote:
>

>> The 'lets push more bytes down the pipe and across all those
>> routers' thinking is not going to lead to performance. You may
>> be scalable but performance will suffer. And you will be no
>> more scalable than a thinner client.

>
> Well, I actually want thin clients, but from DBMS perspective,
> the application server is not a thin client. I do believe that
> no bytes should leave the DBMS that aren't needed at the end
> client, but once they've left, they should be retained and
> milked/reused for all they are worth,

To a point. But, the worry here is that the developer starts down this path and ends up coding joins in the middletier. Stay away from that and I agree.

> and this can be intelligently and profitably done. Performance
> and scalability follow, according to the non- volatility of the
> data,

Can you explain further?

> the relative proximity of the clients to the middle tier as
> opposed to their distance to the DBMS, and the relaitve
> lightness of the communication protocol between client and
> middle tier as opposed to the protocol between DBMS and any of
> it's clients.

But how "close" is the client to an EJB that has been passivated and needs to be reactivated? What is the database but one huge passivation/activation engine? It is clearly better at that job than an application server. The point is that EJB's have never really taken off because of performance and most will turn around and just constantly query that database. We do this in our environment and our performance is quite good.

>> Render under to database everything you can do in the database
>> and let the middle tier do what it does best ... fail-over,
>> load levelling, and serving up the front-end.

>
> Sure, and protecting the DBMS from uncontrolled ad-hoc
> connections and mindless repeat queries,

What is a call to an EJB but a mindless repeat query to some passivation/activation engine?

> and acting as a transaction monitor/controller to get the best
> performance out of the DBMS, etc.

I agree that logical transaction control should be performed by the client requesting the operation and distributed transactions are certainly handled quite nicely. But, if your distribution is all Oracle, then I would still say to handle it within Oracle.

-- 
Galen Boyer

Received on Wed Jan 21 2004 - 09:39:05 CST