Browse Prior Art Database

Incremental update technique for mirroring data from slow speed storage to fast access storage

IP.com Disclosure Number: IPCOM000016193D
Original Publication Date: 2002-Aug-12
Included in the Prior Art Database: 2003-Jun-21
Document File: 3 page(s) / 89K

Publishing Venue

IBM

Abstract

Disclosed is a software algorithm to solve the following problem A software application written in Java is commonly a set of class files which have been compressed and combined into Jar or Zip files. Jar/Zip files are more convenient for builders and installers as there are fewer files to manage, and are more convenient for customers as they take up less space. Even compressed, a large application set may require dozens of Jar/Zip files that each can be many megabytes. Usually these Jar/Zip files are stored locally when an application is installed, as local hard drive access time is much faster than if the program was stored on a LAN drive or brought over the network each time you needed to run it. Note that this disclosure is described in terms of a Java application example, however, the concepts could be used to update any arbitrary set of files with a master version of that file set. As another example, think of a master web server that wants to update copies of its web pages to a mirror web site.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 3

  Incremental update technique for mirroring data from slow speed storage to fast access storage

Disclosed is a software algorithm to solve the following problem - A software application written in Java is commonly a set of class files which have been compressed and combined into Jar or Zip files. Jar/Zip files are more convenient for builders and installers as there are fewer files to manage, and are more convenient for customers as they take up less space. Even compressed, a large application set may require dozens of Jar/Zip files that each can be many megabytes. Usually these Jar/Zip files are stored locally when an application is installed, as local hard drive access time is much faster than if the program was stored on a LAN drive or brought over the network each time you needed to run it. Note that this disclosure is described in terms of a Java application example, however, the concepts could be used to update any arbitrary set of files with a master version of that file set. As another example, think of a master web server that wants to update copies of its web pages to a mirror web site.

The problem is that if an application changes frequently, and the user wants or needs to have the latest Jar/Zip files installed locally, there can be frequent delays waiting for all the new files to be installed locally from some slower speed storage device such as a CD or LAN drive. With Java RMI applications the client code must be kept in sync with the server code, as this requirement is enforced by Java itself. Unmarshalling errors commonly occur when client code build date does not match the server code build date.

The idea is to reduce the refresh delay by only updating a subset of each local Jar/Zip file. That is, only update any individual file contained in a Jar/Zip file if it has actually changed from the previous version.

The problem is complicated by the fact that a Java build process can force all Java class file to be "built," which updates the class file's last changed date, when in fact the resulting binary file is identical to the original class file.

Another problem to solve is that when a refresh program attempts to inspect a large Jar/Zip file by reading it from the slower storage device, a long delay can occur because the entire file is effectively copied locally from the CD or LAN drive to accomplish this (even though it is done automatically by the file system).

Solution - The solution is based on a feature of a Jar/Zip files which can return the checksum of a file inserted in it. The checksum is used to determine if a class file on the user's system is the same as the freshly built class file in the "newer" version of the Jar/Zip file.

The solution consists of a couple things, first, whenever a new application build is performed, a manifest file is created. The manifest file contains a list of the files in each Jar/Zip file and the corresponding checksum for each file. These checksums are provided automatically by...