Hi all,

I am busy reading Rod Johnson's excellent book "Expert one-on-one J2EE Design and Development". The most helpful book I have read in years.

In several places in his books he refers to the benefits of co-locating the web tier and biz tier within the same JVM and the on the same phsycial machine. One then uses clustering to handle scalability.

My question is how about the database. This point seems to be glossed over in the book. Most enterprise systems I have dealt with have the database on a seperate physical machine to the business and/or web machines. This is for the purposes of backup, security and shared access.

However, this obviously neccessitates remote access to the DB machine for every DB interaction from any business object. Doesn't this kill performance in the same way as making your EJBs distributed does (as opposed to co-locating them). Or does connection pooling and the lower access overheads (when compared to RMI) make this performance loss negligble?

Any input on this topic would be most helpful as my company is in the process of finalising it's hosting, machine and design requirements.

Many thanks in advance.

Wayne

Having your db and jvm on the same machine would be fine for development, but not recomended in a production environment, especially if you are talking about a high volume application. Your box would then be responsible for both the work load of the site and the work load of the db.

Anyway you look at it, you are going to have to deal with some network overhead. Minimizing this to the least number of network calls what you should be striving for. The book describes a very well, thought out, DAO package. Eliminate EJBs altogether and use the DAO. You can cache the data from the DAO and have JMS send notifications on when the db has changed.

I hope this helps.

Wayne,

In my experience, hosting the database on the same server is unusual. The network hop to the database is usually a necessary evil, which produces more benefits than distributed objects do. (Note that in a distributed object architecture the issue is an additional network hop in the Java layer, as the database will still normally be on another machine.) Often it's desirable to run a cluster of J2EE servers against the same database; often database admin can be an issue when there are J2EE servers on the same box. Also, you may want to use a different database in a staging environment.

Yes, connection pooling can reduce the cost associated with DB access. But it's one reason that you often want to cache data in the Java layer.

If you're dealing with a small scale app that will never be clustered, of course it might make sense to co-locate the database.

Regards,
Rod

Rod Johnson
http://www.springframework.org