On May 10, 3:10 pm, SomeDeveloper <somedevelo...@gmail.com> wrote:
> Hello,
>
> I am very new to distributed computing and mySQL, so *kindly* forgive
> my ignorance.
>
> Has anyone recently (or, ever) attempted this, or is planning to
> attempt this in near future... with mySql (or, any other RDBMS for
> that matter)?
>
> Writing an enterprise-class application...
> ... NOT with the typical architecture of a J2EE/.NET application;
> ... but rather, with the 2-tier, client/server architecture (popular
> in the 1980's);
> ... with the RDBMS acting as the application server ;
> ... with *ALL* the business logic coded via stored procedures;
> ... with Tomcat/Jsp as the presentation/client tier;
> ... with clustering / load balancing to be achieved via Tomcat/RDBMS/
> xyz? ;
> ... with JDBC calls to raw sql statements or stored procedures from
> servlets;
> ... that scales to at most a few thousand (not millions of)
> concurrent users?
>
> I'm very well aware that sql and stored procedures are not portable
> between RDBMSes. But RDBMS-independence is not at all my goal here
> (let's say). Let's say, my goal is to stick to only a single RDBMS
> (mySql), and then fully and completely leverage every bit of power
> offered by sql and the procedural/relational paradigm for extremely
> rapid enterprise application development.
>
> What I'm hearing from typical J2EE peers of mine is...
> * that the (JBoss-like) application server is where you should put
> all your business logic;
> * that you must use (kodo-/hibernate-like) framework to convert from
> relational to OO;
> * that this approach helps offload the computation load from the
> database server to the application server;
> * that J2EE architecture allows you to scale out and throw in more
> app servers to handle increased user loads in future.
>
> What I don't understand is that even if you use kodo/hibernate and
> scale out in app server tier, wouldn't the database tier still remain
> a bottleneck if you don't scale it out as well (via clustering)? For
> example, if in the kodo/hibernate layer you need to perform the
> equivalent of a join over N tables, the individual rows of these N
> tables (during the join) will still come ultimately from the N
> 'select' statements executed in the database tier?
>
> I read somewhere on the Net... that the 2-tier client/server
> architectures have long been discarded in favor of 3-tier or N-tier
> architectures. The explanation typically involves use of an
> intermediate application server. But if I decide to use my clustered
> RDBMS as my application server, do you see any problems with runtime
> application performance? Do you see any other problem (other than
> portability problems, non-object-oriented biz logic, ...)?
>
> Would greatly appreciate if you could also point me to any relevant
> info / links on this subject. J2EE / .Net books won't tell me anything
> other than what they have to offer.
>
> Regards,
> /SD.

Hello again,

The above question of mine probably is best articulated via this
paper: http://web.inter.nl.net/users/T.Kopp...DB_CENTRIC.doc

The only problem is that this paper talks about Oracle :-( .

Would really, *really* appreciate if folks who have implemented the
thin / thin / fat model with mysql (or, if they have not implemented
it but can readily see some red flags) can share their experiences /
insights.

Regards,
/SD