Manual Caching and Automatic Caching for Programs

By Brien M. Posey | Dec 19, 2000 | Print this Page
http://www.enterprisenetworkingplanet.com/netos/article.php/625411/Manual-Caching-and-Automatic-Caching-for-Programs.htm

In Part 1 of this series, I discussed the idea that Windows 2000 allows you to cache network-based files and folders so that mobile users can use them on the go, just as if they were attached to the network. In that article, I explained that there are three distinct types of caching for files and folders: automatic caching, manual caching, and automatic caching for programs. In this article, I'll continue the discussion by explaining the pros and cons of manual caching and automatic caching for programs.

Manual Caching

As I mentioned in Part 1, manual caching works best for users who need access to a large number of files or directories. The only significant downside to manual caching is that it requires user intervention. The biggest issue that mobile users need to keep in mind about manual caching is that there are no preset cache size limits. Therefore, it's possible for a user to run low on hard disk space by caching too much data. According to Microsoft, the amount of data that can be manually cached is limited to 2 GB. However, if the hard disk on the mobile computer has less than 2 GB of free space, nothing will stop the mobile user from running the machine out of space with cached files.

Automatic Caching for Programs

The Automatic Caching for Programs option allows mobile users to access network-based programs while working offline. For example, suppose your users run Microsoft Word by double-clicking on an icon that points to a copy of Microsoft Office that's stored on a network share. In this case, under normal circumstances, mobile users won't be able to use Microsoft Word while on the go. However, automatic caching for programs can make a program such as Microsoft Word available to mobile users even when they are working offline. Unfortunately, there are some very serious issues that you'll encounter when using this feature.

To understand why automatic caching for programs can be problematic, consider the way that automatic caching works in general. In the basic implementation of automatic caching, files are cached only when accessed. The same thing happens in automatic caching for programs. To see how this affects mobile users, let's return to my earlier example of a user who wants to use Microsoft Word while offline.

If a mobile user attempts to use a network-based copy of Microsoft Word (or any other program) while offline, what they will be able to do depends on several factors. Remember that automatic caching only caches files as they are accessed and replaces cached files with newer files as the cache fills up. This means that if a mobile user has never accessed Microsoft Word while online, then the program won't be available to them offline. Likewise, if the mobile user has previously used Microsoft Word while online, but has accessed other automatically cached files since then, Microsoft Word may or may not be available, depending on whether the cache had to remove files to make room for new files.

It would seem that when mobile users need to use a program offline, they need to open that program just before they disconnect, to make sure it will be available when working offline. Actually, this isn't entirely true. Remember that only the program files the user has accessed will be cached. Therefore, if a user doesn't use all of the program's features, there's a good chance that not all of the program's files will be cached. For example, suppose a mobile user opens Microsoft Word just before disconnecting. Later, when the user tries to use Microsoft Word while offline, he will be able to access the programbut because not all the files have been cached to the local hard disk, some features (such as the spell check) won't be available. If, however, the user had opened Microsoft Word while online and used the spell check at that time, then the spell check files would have been cached (disk space permitting) and the spell check feature would now be available offline.

The other major problem with caching programs is that not all programs can be cached successfully. For example, suppose your organization has a proprietary order-entry program that acts as a front end to a database. If a mobile user attempts to cache this program, she may or may not be able to do so successfully, depending on how many of the necessary databases and indexes she accesses. Another factor is how many other users are accessing the database while the mobile user is attempting to cache the database. If information in the database is constantly changing, then the databases and indexes may be out of sync with each other by the time the caching process completes. Likewise, if the user makes changes to the database while offline, Windows 2000 will attempt to synchronize those changes when the user reconnects. The synchronization will be unsuccessful, because Windows synchronizes offline changes at the file levelbut database synchronizations are usually performed at the record level, rather than at the file level.

Finally, there's the issue of size. Even if you could guarantee that no other users would touch the database from the time you began caching it to the time you reconnected to the network, there's a good chance that you wouldn't be able to cache the necessary databases because of their size. After all, you can't cache a 20 GB database on a laptop that only has a 10 GB hard disk space. As you can see, caching programs presents some serious problems. If possible, it's usually better to simply load a program locally onto a laptop's hard disk than to try to cache it.

CrossLinks

Conclusion

As I've explained in this article, there are issues to consider when you attempt any type of caching. Now that you understand how caching works and what the issues involved are, I'll conclude the series in Part 3 by explaining how to enable caching. //

Brien M. Posey is an MCSE who works as a freelance writer. His past experience includes working as the director of information systems for a national chain of health care facilities and as a network engineer for the Department of Defense. Because of the extremely high volume of e-mail that Brien receives, it's impossible for him to respond to every message, although he does read them all.