Best Way to place temporary Data for an Webapp

Question

My newest project is able to generate documents with information from a database.

So I copy the document template on demand to an temporary folder for a user and modify it. I do this because every template must be available during modification.

Afterwards the user is awarded with his document via a download link from my webapp.

My question: Is there a best practise for sorting webapp data...I thought temp would be nice for it. But since I have to delete the data by myself I thought of placing it besides my WAR folder in the tomcat webapp folder.

I use Windows 2003 as a host system with Tomcat. I use Grails, Java and Maven for my project...don't know if this information is needed.

Edit: Main reason why I ask this trivial question is...if I take care of creating/deleting my temporary data...is it still a good practise to use temp folder on the system? I am not sure about this...

Answer 1

When storing (sensitive) user-specific files in webapp, ensure that you store it somewhere in /WEB-INF and access them with a Servlet which (indirectly) checks the logged in user, otherwise it's accessible for any user/hacker on the world wide web. The advantage is that it's easy accessible programmatically by ServletContext#getResource() or #getRealPath(). The disadvantage is that they will get lost whenever you redeploy the webapp.

You can also store them in the default temporary folder. The advantage is that it is accessible by standard API's like File#createTempFile() or System.getProperty("java.io.tmpdir"). The temporary folder has the disadvantage that OS-controlled folder cleanup is not controllable from Java, so you may risk the stuff get lost whenever you close the resourse but would still need it later.

You can also store them in a fixed folder outside the webapp. It has the advantage that the stuff don't get lost whenever you redeploy the webapp. The disadvantage is that you need to create the folder yourself with sufficient OS rights, which may not be applicable in 3rd party hosts.

Cleaning your own temporary resources certainly belongs to the tasks you need to do yourself. I wouldn't consider it as a concern.

Just outweigh the advantages/disadvantages.

Answer 2

I believe that temporary files belong in a temporary folder. In your case, you delete the files yourself, but what if there's a bug in the file deletion operation? Or what if there's a server shutdown before the files are deleted? If you write to a temporary folder, there's at least some hope that the files will be cleaned up later (manually or by some process).

Even when an application wishes to store persistent data (i.e. not temporary), I think it still shouldn't be stored in the Tomcat directory, because those directories tend to be deleted or overwritten whenever you deploy a new version of your application (or even install a new version of Tomcat).

Useful methods:

• java.io.File.createTempFile
• System.getProperty("java.io.tmpdir")

Answer 3

• Storing information within the web application folder does not always work. Some application servers do not expand the deployed WAR file and hence there is no "working directory" for a web application. Some sys admins also prevent web applications file system access (that depends on the security manager policies).
• Temporary files should be used for, well, temporary data. Data which can be reconstructed on demand. Do not use temporary files which ought to be downloaded by users. E.g. when your system thinks it should clean up temporary files or when you restart the application server, the user still wants to download this files although they might be deleted in the mean time.
• The right place to store such data is the database. Your documents are not really temporary in the means of temp files. Use a database to store the documents and use the database as a cache for documents. You can then implement your own cleanup strategy. It also serves as a persistent storage, so you don't have to worry about server restarts. Also, you can have additional meta-data in there, such as last access time or an access counter and easily provide the user with a list of documents he created. If your document processing library requires a java.io.File for manipulation, only then store the document from the database into a temp file, start the processing and read it back into the database.