3

I am using a file and need to update value in java when file is modified. So, I am thinking to check modified time using lastModified of File class, and if modified read the file and update single property from the file.

My doubt is, is lastModified as heavy as reading single property from the file/reading whole file. Because my test results are showing almost same results.

So is it better to read file and update property from the file everytime or checking lastModified is better option in long run.

Note: This operation is performed every one minute.

Or is there any better option than polling lastModified to check if file has changed. I am using java 6.

codingenious
  • 8,385
  • 12
  • 60
  • 90

2 Answers2

5

Because you are using Java 6, checking the modified date or file contents is your only option (there's another answer that discusses using the newer java.nio.file functionality, and if you have the option of moving to Java 7, you should really, really consider that).

To answer your original question:

You didn't specify the location of the file (i.e. is it on a local disk or a server somewhere else) - I'll respond assuming local disk, but if the file is on a different machine, network latencies and netbios/dfs/whatever-network-file-system-you-use will exacerbate the differences.

Checking modified date on a file involves reading the meta data from disk. Checking the contents of the file require reading the file contents from disk (if the file is small, this will be one read operation. If the file is larger, it could be multiple read operations).

Reading the content of the file will probably involve read/write lock checking. Generally speaking, checking the modified date on the file will not require read/write lock checking (depending on the file system, there may still be consistency locks occurring on the meta data disk page, but those are generally lighter weight than file locks).

If the file changes frequently (i.e. you actually expect it to change every minute), then checking the modified date is just overhead - you are going to read the file contents in most cases anyway. If the file doesn't change frequently, then there would definitely be an advantage to modified date checking if the file was large (and you had to read the entire file to get at your information).

If the file is small, and doesn't change frequently, then it's pretty much a wash. In most cases, the file contents and the file meta data are already going to be paged into RAM - so both operations are a relatively efficient check of contents in RAM.

I personally would do the modified date check just b/c it logically makes sense (and it protects you from the performance hit if the file size ever grows above one disk page) - but if the file changes frequently, then I'd just read the file contents. But really, either way is fine.

And that brings us to the unsolicited advice: my guess is that the performance on this operation isn't a big deal in the greater scheme of things. Even if it took 1000X longer than it does now, it probably still wouldn't impact your application's primary purpose/performance. So my real advice here is just write the code and move on - don't worry about it's performance unless this becomes a bottleneck for your application.

Kevin Day
  • 16,067
  • 8
  • 44
  • 68
4

Quoting from The JAVA Tutorials

To implement this functionality, called file change notification, a program must be able to detect what is happening to the relevant directory on the file system. One way to do so is to poll the file system looking for changes, but this approach is inefficient. It does not scale to applications that have hundreds of open files or directories to monitor.

The java.nio.file package provides a file change notification API, called the Watch Service API. This API enables you to register a directory (or directories) with the watch service. When registering, you tell the service which types of events you are interested in: file creation, file deletion, or file modification. When the service detects an event of interest, it is forwarded to the registered process. The registered process has a thread (or a pool of threads) dedicated to watching for any events it has registered for. When an event comes in, it is handled as needed.`

Here are some links which provide some sample source on implementation of this service:-

Link 1

Link 2

Edit:- Thanks to Kevin Day for pointing out in comments, since you are using java 6 this might not work for you. Although there is an alternative available in Apache Commons IO . But have not worked with it, so you have to check it yourself :)

Mustafa sabir
  • 4,130
  • 1
  • 19
  • 28
  • Ohh yes , missed that . I used this thing once and it works like a charm , just needed to modify the directory path and monitoring parameters in the java provided code. Continously polling filesystem and checking lastmodified seems a bit trivial. There is an alternative using `ORG.APACHE.COMMONS IO` classes , But havent worked with them. Will mention them in the edit, thanks :) – Mustafa sabir Aug 26 '14 at 12:37
  • I haven't checked the code, but my guess is that org.apache.commons.io drops back to polling under Java 6. Unless apache is deploying a native library (doubtful), it just isn't possible to hook into the file system notification system... The nice thing about using a library like commons.io is that it nicely encapsulates the polling - but really, this sort of thing is just 3 or 4 lines of code and pretty easy to implement ad-hoc. – Kevin Day Aug 26 '14 at 12:51