Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > Java > Java and JDK > BOOK: Expert One-on-One J2EE Design and Development
Password Reminder
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
BOOK: Expert One-on-One J2EE Design and Development
This is the forum to discuss the Wrox book Expert One-on-One J2EE Design and Development by Rod Johnson; ISBN: 9780764543852
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Expert One-on-One J2EE Design and Development section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old July 22nd, 2003, 08:52 PM
Registered User
Join Date: Jul 2003
Location: , , Singapore.
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Default Distributed vs Co-located DB performance

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.

Reply With Quote
  #2 (permalink)  
Old August 5th, 2003, 08:58 AM
Registered User
Join Date: Aug 2003
Location: Center Valley, PA, USA.
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via MSN to dmfrey Send a message via Yahoo to dmfrey

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.
Reply With Quote
  #3 (permalink)  
Old October 22nd, 2003, 05:20 AM
rod rod is offline
Registered User
Join Date: Oct 2003
Location: , , .
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts


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.


Rod Johnson
Reply With Quote

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
excel file cant be located RoniR ASP.NET 1.0 and 1.1 Professional 1 February 19th, 2007 08:05 AM
Has anyone located all of the source code yet? gary167 BOOK: Access 2003 VBA Programmer's Reference 0 November 10th, 2006 08:21 PM
What object is streamwriter located under? kenn_rosie ASP.NET 1.0 and 1.1 Basics 0 February 21st, 2006 08:10 PM
Major performance loss on split DB roniestein Access 67 October 22nd, 2004 11:55 AM
Distributed vs Co-located DB performance wsalamonsen J2EE 1 July 23rd, 2003 05:31 AM

All times are GMT -4. The time now is 08:25 AM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.