The object oriented approach is always a good idea, but the biggest benefit is seen when you mostly use client objects. The server-side approach requires you to develop much of the code and objects, since there are no standards available for high level development. You will also spend a considerable amount of time, playing around with state management and scaleabililty issues. These issue may disappear in a client-side approach.
First, not all of the needed technologies, CORBA, IDL, RPC, and database access, are available as Java APIs. These are beginning to emerge, but they are not yet available on all platforms, are not yet implemented by many vendors, and mostly use native methods, which limits their portability.
Although Java allows you to implement your own native methods, it is tedious to do so and you must port those methods to other platforms. Even if you have a native library, you must develop Java wrapper code to use it. Portability for server-side is not a requirement for many developers. These developers are committed to delivering the Web site on a particular platform. They may also want to exploit the full capabilities of that platform. These capabilities are not yet available in Java and will limit portability. Also, other languages, like C/C++, are portable at the source code level. Java on the client side is very attractive, since the actual executable (Java byte codes) must be downloaded to the client and run.
However, using Java does not guarantee that you will use threading correctly. You may still corrupt data. You are more likely to make a mistake in a more complex application, which server side only programming leads you to. Each case must be analyzed carefully.
Another problem for threaded Java code is that the garbage collector, which reclaims memory, may never run in a busy Web site until all real and virtual memory has been used up. This would bring a Web site to its knees. It may take specific calls to the garbage collector to reclaim, although this approach is not guaranteed to work on all operating systems.
Another problem (also not portable) is the limitation on the number of threads that can be concurrently running on a processor. The default stack size for a thread is 1MB on most OSs. Some OSs require that the virtual address space for the thread's stack be reserved at thread creation, others don't. Both models present problems. In the reserved case, the virtual address space (typically 2GB in the user space) will lead to a maximum of 2000 threads.
Playing with the stack size is possible but extremely dangerous and will usually come back to haunt you. In the non-reserved case, a thread may need to use its full stack space only to find it not available and the thread and maybe the application will fail.
Since many of these mechanisms are performed in the kernel, there can be a heavy penalty for these in terms of time. In some cases the threads will follow each other in lock step through the code. If you design a library for threaded use, then the library may run slower in a non-threaded application because locks must always be acquired.
Java uses interpreted byte codes for portability. As such it also runs slower than native code. You could use just-in-time compiling to produce Java applications which rival the speed of native code, but these applications cannot be run on another OS without a just-in-time compiler.
Just-in-time compilers are not yet available on all OSs even if the Java Virtual Machine is available. Having a server application which always runs slower than a native application is not what the users want.
So does this mean that Java doesn't work? Not at all. Java is a general purpose language that can be used in the client browser, the web server, or without the Internet at all. It has is greatest use as a cross platform solution for the Web client. Java however needs a little more refinement and track record for wide spread on the Web server. Does the above discussion say that threading should not be used? No, but threading is a tool that is best when used judiciously and not as a widespread tool for general programming tasks. The problems described above are the limitations that you will face if you try to build the ultimate server site to support a server-side only programming solution.