Need help with Synergy's use of cache?

Glyn_Mo's picture
Glyn_Mo asked on February 21, 2011 - 8:51am | Replies (4).

I'm wondering if anybody knows when exactly a cache value is generated for a Synergy object?

Is a cache value for an object generated by simply opening viewing an object from the GUI, in addition to when you create an object and perform a "Use" on the object?

I've noticed that if a cache value for an object is deleted on the file system, viewing the properties of the object in Synergy still shows the object as having the CVID of the cache value deleted from the file system. Opening the said object from Synergy then re-creates the object in the cache on the file system.

If an object has its cache value deleted from the filesystem (as opposed to using clean_cache), is it possible that the same cache value could be used again by another object?

Is there a command specifically to cache/re-cache a Synergy object?

The reason I ask is that for deployment of code, our DBAs actually copy the object from the cache as opposed to copying it from a project workarea. This means that we cannot regularly run the clean_cache command, which we are desperate to do in order to reduce the backup time.

I wish to be be able to run the clean_cache command regularly as all Synergy documentation and people I've spoken to recommend, but be able to re-cache object when required for deployment.

If anyboy has any knowledge anout Synergy cache use in general, it would be very much appreciated.

Thanks
Glyn

4 Answers

David Honey's picture

Hi Glyn,

If a cache file is missing for an object that has been previously archived, this means that a user must have performed a [i]ccm clean_cache[/i] command on it. That command verifies, before removing the cache file, that the same contents can be successfully retrieved from the archive.

The cache file represents the full source contents of a versioned file. All other attributes are stored in the underlying database, typically Informix. The cache file will be restored automatically from the archive when any of the following happen:
[ul][li]If you view the source through edit, view, ccm cat[/li][li]If you compare its source with diff or merge[/li][li]If a copy-based work area is updated (synced)[/li][/ul]So one way of ensuring that the cache file is present is to do something like:[code]ccm cat filespec > /dev/null[/code]
If you have a link-based work area, then it is possible that the [i]ccm clean_cache[/i] command will remove from the cache a file that is linked to from a work area if you use the [i]-u[/i] option. That is not the default behavior.

I do not know what you mean by "cache value". Could you give an example of what you mean?

In general, scripts that assume that the cache file will contain the object they want are likely to be fragile. Any use of ccm clean_cache is likely to break it. Instead, using ccm cat to copy the file somewhere else would be more robust. It also deals correctly with any required end-of-line conversion for the client on which the command is executed.

Regards,
David.

Glyn_Mo's picture
Glyn_Mo replied on February 22, 2011 - 12:51pm.

Hi David

What I mean when I say "cache value" is the physical cached object which sits on the server in the $CCM_HOME/$DB_NAME/st_root/cache/source/ directory.

When deploying, our DBAs actually retrieve the cached object from this directory. This means we've been unable to run the clean_cache command because if an object's not cached, then they can't retrieve it.

I want to be able run the clean_cache command every night in order to reduce the time the backup takes to create the pack file. This is currently takes hours because we can't clear the cache. In order that we can still use our same deployment scripts, I want to be able to re-cache each object required to be deployed. At the moment ever single version of every object is cached, which is not desirable.

Thanks
Glyn

baynes's picture
baynes replied on February 23, 2011 - 4:04pm.

If they are going direct to the cache and not via a workarea then you have a major issue on your hands as who knows what they are picking up - it could easily be the wrong thing. Access should always be via a workarea. If they can't be trusted to use a link based workarea then remove their read access to the cache and give them a copy based workarea instead.

Go ahead and run the clean cache anyway. If it removes a file not in a project that someone relies on then it will bring it to their attention they are doing things the wrong way.

David Honey's picture

If you have scripts that are based on an assumed understanding of the layout of files under the dbpath/st_root directory, then such scripts are potentially fragile.

The layout of files under dbpath/st_root is implementation private, undocumented, and subject to change.

We have already made such changes relating to archiving over several releases. Scripts should not depend on or assume anything about what is under the dbpath/st_root directory.

David.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.