I am building an application wherein the user would have an option to upload files (can be documents or images) and once the files are uploaded the user should be able to download it.
I am using Apache Tomcat 6.0 and JDK1.6.
Every thing seems to be OK for the File Upload part but I have some questions in my mind for the File Download Part.
Initially I tried to use the BLOB feature of the mysql Database to save the file as a Binary stream in the DB. However after googling it out I found out that there are serious performance issues with BLOB (The file size can be anywhere from 1 KB to 20 MB). Thus we have ruled out this approach.
We decided to save the file path in the DB and save the file to the File System.
For this, Initially we stored the files under the Root directory of the application but the Tomcat could not recognize the files until it was refreshed/restarted.
This can’t be accepted for the realtime environment.
One fix we found out for this was to create a new file directory under the web-apps folder of tomcat outside the root directory of the application and save the files in this directory. To make this work we added a new context to the tomcat configuration.
Please suggest if this is the best approach to follow.
I got burnt very badly when I inherited a project that was storing images inside the WAR directory. First software upgrade, and "BAM!" All the images are gone.
Besides, you can't upload files into a WAR unless it's an exploded WAR. And exploded WARs actually aren't part of the J2EE architecture. They're a "feature" of some, but not all J2EE appservers. In fact, while some versions of Tomcat would automatically explode WAR files, some don't appear to, and it's a configurable option on most of the recent ones, I think.
It can be a problem, however, using an external data directory, since that codes a dependency on your server's filesystem into the app. A good way of getting around that is to define the directory path as a web.xml resource and look it up via JNDI. In Tomcat, you can override the default value in web.xml without actually having to modify web.xml itself. Although even that's better than having to change source code and recompile.
Blob avoidance is one of those Urban Legends. I wouldn't just assume that because someone says so that they're always going to be a bad solution, but rather do an app-specific case study. Obviously, as always, abstracting your storage mechanism will help in switching mechanisms once you find which way you want to go. And change that mechanism later, if it proves profitable.
Oracle 11 was claiming that database accesses were faster than file accesses, for example. YMMV.
One thing I do know from my own project. It can be a real pain when the images are in the filesystem when you're using the database on a separate test machine.
Customer surveys are for companies who didn't pay proper attention to begin with.