RMI is the way to go. Definitely.

J2EE is also designed for such things, but it can be a pretty heavy architecture for a simple client-server app.

why reinvent the wheel when there are perfectly good solutions like Hibernate and Spring already out there?

Thanks for the suggestions! Isn't Hibernate an implementation of RMI?? anyway....

Hypothetically speaking, if an application need to scale from 50 to 500,000 users(disregarding hardware issues) would all three tiers really be necessary? Could we just go with:

many clients <----> Server <----> Database ???

Although I guess the 3rd Tier allows for better control of say, connecting to different types of databases though...

And although yes, Hibernate/RMI seams like the way to go, I think all would agree setting up a simple client server from scratch or playing with a code sample is probably better starting out to learn the bare bones first. At least I find that jumping into something more complex without first seeing the different parts in action just complicates the matter.

No, Hibernate abstracts away all that nitty gritty JDBC code to access the database.
http://www.hibernate.org

You shouldn't care whether you're talking through RMI or whatever, use an existing system to worry about that.

Spring makes for a lot of very nice capabilities. http://www.springframework.org/

Depending on your application one of the 2 approaches can be chosen.. If you have enough complexity in DB parts OR more than one servers connecting to DB layer, you might want to have database server separately..
In anycase as Ezzarel pointed out J2EE is designed EXACTLY for this purpose.. See this architecture diagram.. it's not mandatory to have 2 physically different machines for J2EE and DB server, both can be on one machine..

i suggest:
hibernate for data layer
spring for MVC
freemarker view layer
dwr for ajax