Improving Replication Performance
Windchill offers two technologies enabled by the same option that accelerate the handling of content data and expedite collaborative development.
• Local upload—Places a user’s uploaded content in the local cache vault as an intermediate location before it is transferred to a master site during a synchronization (sysForceSync) operation.
|
|
Content is also transferred to the master site when the master site receives a request for content that is only available at the remote site.
|
• File Server—Creates a location for rapid access to frequently requested content data.
Both technologies depend on a designated cache vault in the remote site. These technologies are transparent to the Windchill user and can be incorporated in applications. The technologies deliver the following benefits:
• Faster check-in for the user
• Faster and earlier access to cache content data for users with shared download preferences
• Availability of data to all users always
• Ability to determine the check-in status on the master site
• Data mirroring on the cache vault site to safeguard data against failure
• Conformation of remote site structure to rules
• Data that is searchable by all users after it is indexed on the master site
• JavaBean for easy incorporation of local upload functionality in applications
How the Local Cache Works
The following graphic illustrates how the local cache works:
Following is the key for the graphic:
• A—Vault on master site.
• E—Local cache vault on cache server site.
• E1—A physical path on the file system corresponding to a folder to be used for mirroring in the local cache vault. Mirrored paths for folders cannot be used for downloads from the remote site.
• E2—A physical path on the file system corresponding to a folder that reads from and writes to the local cache vault.
• G1—A host whose users share the same site preference for downloads. The site preference is set to the remote site sE that also contains the local cache vault.
• G2—A host whose users have their download site preference set to a remote site sH that does not contain a cache vault.
• g1e1—Mounts to the mirroring folder in the local cache vault.
• g1e2—Mounts to the readable folder in the local cache vault.
• H—A vault that is not a local cache vault and is in another site sH. This site is the preferred download site for the user of host G2.
• sA—Master site for sites sE and sH.
• sE—Remote site that includes a local cache vault and is the preferred download site for users of hosts G1.
• sH—Remote site that does not include a local cache vault and is the preferred download site for the user of host G2.
The time required for a user to check in, create, read, and update files is reduced, because these interactions involve data on the rapidly accessible cache vault rather than the more slowly accessible vaults on the master site. Unless these content files were requested earlier, they are replicated to the master site according to the sysForceSync synchronization schedule.
For example, when a user of host G1 checks in data, the checked-in copy is stored in local cache vault E rather than master site vault A, which would be the check-in vault if the local cache enhancements were not enabled. The data will be copied from vault E to vault A when an applicable sysForceSync synchronization schedule becomes active or when a request for the data arrives at site sA.
If users set their content cache preference to the remote site that holds the local cache vault, they can access data located there more quickly than users who only have access to that data on the master site. For example, if a user on host G1 wants to access content checked in by other user on host G1, the content is downloaded from local cache vault E, rather than the less rapidly accessible vault A on the master site. Not only is the access time reduced, but the data is also available earlier because of the faster check-in time on local cache vault E compared to master site sA.
If the master site receives a request for data that exists only in the local cache vault of remote site, the data is pulled from the remote site. For example, if the user on host G2 requests content that exists in vault E, the content is downloaded to host G2 and copied to vault H. The content is not transferred automatically to site sH if adhoc caching is disabled.
Because this is transparent to
Windchill users, there may be a need for clarification about whether data checked in to the local cache vault E has been copied to the site sH. For more information, see the section Utility to Assist Backups in
Administering a Local Cache Vault.
Maintaining two copies of data within the local cache vault protects it from loss or damage. Each local cache vault folder accessed by read and write operations can be associated with a folder that mirrors it when mount paths for both folders are specified in the same entry during configuration. If the folder that is accessed for read and write operations cannot be read, the contents of the mirror folder can be copied to the readable folder so that the read operation can continue. For example, the mount path g1e2 associates the readable folder E2 with the host G1, while the mount path g1e1 associates the mirroring folder E1 with the host G1. For more information about mirroring, see the section Establishing Mirroring in the Local Cache Vault in
Administering a Local Cache Vault.
When content has been replicated from the local cache vault to the remote site, it exists in both locations. If its structure in the local cache vault violates a rule, the violation is corrected when the rule becomes active.
Indexing is the collection of keywords from content to make it searchable. Data in the local cache is not indexed. Data is indexed when it moves from the local cache vault to the master site.
A download and upload JavaBean are available to implement the feature in applications. The Windchill Customization Guide describes this bean.
