28

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

So I copy the document template on demand to a 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 practice for storing webapp data ? I thought temp would be nice for it. But since I have to delete the data 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 practice to use temp folder on the system? I am not sure about this...

Mr_and_Mrs_D
  • 32,208
  • 39
  • 178
  • 361
bastianneu
  • 2,059
  • 2
  • 18
  • 31

4 Answers4

36

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 easily 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 getting lost whenever you close the resource but 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.

cweston
  • 11,297
  • 19
  • 82
  • 107
BalusC
  • 1,082,665
  • 372
  • 3,610
  • 3,555
  • I wasn't aware that the OS can decide to clean up the temporary folder. Can you elaborate on that? – Eli Acherkan Dec 28 '09 at 14:46
  • 1
    Most server systems run a cron job once per day/week/month which delete all files older than N days from /tmp. This is to make sure that disk space doesn't run out because someone forgot to clean up after themselves. – Aaron Digulla Dec 28 '09 at 14:55
  • 1
    @EliAcherkan: `tmp` should ring a bell anyway – Mr_and_Mrs_D Sep 27 '13 at 20:43
  • Is there any benefit to only writing to a DB instead of saving a temp file? – Jeff Mar 31 '14 at 16:35
13
  • 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.
mhaller
  • 14,122
  • 1
  • 42
  • 61
7

A web container provides a context attribute that points to a temp directory:

Servlet spec SRV.3.7.1 Temporary Working Directories

A temporary storage directory is required for each servlet context. Servlet containers must provide a private temporary directory per servlet context, and make it available via the ServletContext.TEMPDIR (javax.servlet.context.tempdir) context attribute. The objects associated with the attribute must be of type java.io.File.

Example :

File appTempDir = getServletContext().getAttribute(ServletContext.TEMPDIR);
File tempFile = File.createTempFile("process1", ".txt", appTempDir);
tempFile.deleteOnExit();
try {
    ...
} finally {
    tempFile.delete();
}
LoganMzz
  • 1,597
  • 3
  • 18
  • 31
weberjn
  • 1,840
  • 20
  • 24
  • 3
    Just to add to this: Using `File tmpDir = (File)getServletContext().getAttribute(ServletContext.TEMPDIR);` will get you the temporary file directory for the current webapp provided by the servlet container. – daiscog Dec 03 '13 at 17:05
  • This code doesnt seem to be valid... – Jeef May 23 '14 at 09:13
  • @Jeef Why do you think so? – dajood Jul 08 '14 at 10:25
  • Because it wouldn't run without throwing an error – Jeef Jul 08 '14 at 11:03
  • 1
    <% java.io.File tmpDir = java.io.File)application.getAttribute(ServletContext.TEMPDIR); %> <%=tmpDir.toString()%> in a jsp gives for Tomcat C:\Daten\apache-tomcat-8.0.8\work\Catalina\localhost\ROOT – weberjn Jul 09 '14 at 16:24
5

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:

Eli Acherkan
  • 6,401
  • 2
  • 27
  • 34