Above all if you not using whole j2ee arch. & EJB i will suggest you to try TOMCAT instead of apache web server application.
Nevertheless there are thread safe issues with apache..many vendors claims to solve them thou'
i tried to put some light on that ,have a look..
Thread Safety
When using any of the threaded mpms in Apache 2.0 it is important that every function called from Apache be thread safe. When linking in 3rd party extensions it can be difficult to determine whether the resulting server will be thread safe. Casual testing generally won't tell you this either as thread safety problems can lead to subtle race conditons that may only show up in certain conditions under heavy load.
Global and static variables
When writing your module or when trying to determine if a module or 3rd party library is thread safe there are some common things to keep in mind. First, you need to recognize that in a threaded model each individual thread has its own program counter, stack and registers. Local variables live on the stack, so those are fine. You need to watch out for any static or global variables. This doesn't mean that you are absolutely not allowed to use static or global variables. There are times when you actually want something to affect all threads, but generally you need to avoid using them if you want your code to be thread safe.
In the case where you have a global variable that needs to be global and accessed by all threads, be very careful when you update it. If, for example, it is an incrementing counter, you need to atomically increment it to avoid race conditions with other threads. You do this using a mutex (mutual exclusion). Lock the mutex, read the current value, increment it and write it back and then unlock the mutex. Any other thread that wants to modify the value has to first check the mutex and block until it is cleared.
If you are using APR, have a look at the apr_atomic_* functions and the apr_thread_mutex_* functions. [would probably be a good idea to add an example here]
errno
This is a common global variable that holds the error number of the last error that occurred. If one thread calls a low-level function that sets errno and then another thread checks it, we are bleeding error numbers from one thread into another. To solve this, make sure your module or library defines _REENTRANT or is compiled with -D_REENTRANT. This will make errno a per-thread variable and should hopefully be transparent to the code. It does this by doing something like this:
#define errno (*(__errno_location()))
which means that accessing errno will call __errno_location() which is provided by the libc. Setting _REENTRANT also forces redefinition of some other functions to their *_r equivalents and sometimes changes the common getc/putc macros into safer function calls. Check your libc documentation for specifics. Instead of, or in addition to _REENTRANT the symbols that may affect this are _POSIX_C_SOURCE, _THREAD_SAFE, _SVID_SOURCE, and _BSD_SOURCE.
Common standard troublesome functions
Not only do things have to be thread safe, but they also have to be reentrant. strtok() is an obvious one. You call it the first time with your delimiter which it then remembers and on each subsequent call it returns the next token. Obviously if multiple threads are calling it you will have a problem. Most systems have a reentrant version of of the function called strtok_r() where you pass in an extra argument which contains an allocated char * which the function will use instead of its own static storage for maintaining the tokenizing state. If you are using APR you can use apr_strtok().
crypt() is another function that tends to not be reentrant, so if you run across calls to that function in a library, watch out. On some systems it is reentrant though, so it is not always a problem. If your system has crypt_r() chances are you should be using that, or if possible simply avoid the whole mess by using md5 instead. [I don't see an apr_crypt() function.]
Common 3rd Party Libraries
The following is a list of common libraries that are used by 3rd party Apache modules. You can check to see if your module is using a potentially unsafe library by using tools such as ldd and nm. For PHP, for example, try this:
% ldd libphp4.so
libsablot.so.0 => /usr/local/lib/libsablot.so.0 (0x401f6000)
libexpat.so.0 => /usr/lib/libexpat.so.0 (0x402da000)
libsnmp.so.0 => /usr/lib/libsnmp.so.0 (0x402f9000)
libpdf.so.1 => /usr/local/lib/libpdf.so.1 (0x40353000)
libz.so.1 => /usr/lib/libz.so.1 (0x403e2000)
libpng.so.2 => /usr/lib/libpng.so.2 (0x403f0000)
libmysqlclient.so.11 => /usr/lib/libmysqlclient.so.11 (0x40411000)
libming.so => /usr/lib/libming.so (0x40449000)
libm.so.6 => /lib/libm.so.6 (0x40487000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x404a8000)
libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x404e7000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40505000)
libssl.so.2 => /lib/libssl.so.2 (0x40532000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x40560000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40624000)
libdl.so.2 => /lib/libdl.so.2 (0x40634000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40637000)
libc.so.6 => /lib/libc.so.6 (0x4064b000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
In addition to these libraries you will need to have a look at any libraries linked statically into the module. You can use nm to look for individual symbols in the module.
Other imp. issues..
Apache Security
Apache Chunked encoding vulnerability
Requests to Apache 1.3 and Apache 2.0 can cause various effects ranging from a relatively harmless increase in system resources through to denial of service attacks and in some cases the ability to be remotely exploited. (June 18th 2002).
Security flaw found in mod_ssl and Apache-SSL
A buffer overflow has been found in mod_ssl in all versions prior to 2.8.7-1.3.23 (February 23rd 2002).
Major vulnerabilities found in PHP
Major flaws have been found in the popular PHP scripting language commonly used with Apache web servers. These flaws have been found in the way PHP handles multipart/form-data POST requests. Each of these flaws could allow an attacker to execute arbitrary code on the remote system. All versions of PHP from 3.10 to 3.18 as well as 4.0.1 to 4.0.6 are vulnerable.
mod_rewrite canonicalisation
mod_rewrite is a powerful module for Apache used for rewriting URLs on the fly. However with such power comes associated risks; it is easy to make mistakes when configuring mod_rewrite which can turn into security issues.
How to check apache.org distributions
Using PGP or GPG it is easy to check the validity of an Apache distribution you are downloading.
Code Red requests for /default.ida
Don't panic if you see requests for the default.ida file in your Apache access logs. These requests are from the Code Red Worm designed to seek out vulnerable IIS servers.
hope this will solve your issues..
Cheers:)