Purpose

When collaborative editing is enabled, Synchrony is used to synchronise changes made in the editor. This is how multiple people can see each others changes in real time. 

Each page and blog post has its own Synchrony change log, which contains a graph of all edits to that page or blog post. In busy Confluence sites the database tables that store the Synchrony change logs can grow very quickly, and because the change logs store all changes as they happen, they may retain personally identifiable information, even after the page they relate to is deleted.

Solution

From Confluence 7.0 we provide two scheduled jobs for removing Synchrony data:

• Synchrony data eviction (soft)
• Synchrony data eviction (hard). 

The soft eviction job runs regularly in the background. The hard eviction job is available for when you need to remove Synchrony data more aggressively, and is disabled by default. Both jobs remove the entire Synchrony change log for the relevant page or blog post. It's not possible to remove only part of the Synchrony data associated with a page or blog. 

Before exploring how these jobs work in detail, it's useful to understand what we mean when we talk about 'saving changes':

• Synchrony records every keystroke and saves it in the Synchrony change log for the page. 
• Confluence auto-saves the contents of the editor as a draft when someone exits the editor using the Close button, and every 30 seconds while they are in the editor (this auto-save interval is configurable). 
• Confluence attempts to auto-save the contents of the editor as a draft when someone exits the editor by closing the tab or navigating away. If the browser crashes, or there is high latency sometimes this save will fail. Data is not lost, because the next time someone edits the page, the changes will be picked up from the Synchrony change log. 

Soft removal job

This job runs every 10 minutes, and pro-actively cleans up Synchrony change logs that are no longer needed. This helps keep the Synchrony database tables a manageable size. When it runs, the following messages are printed on the atlassian-confluence.log:

2022-01-16 18:12:25,962 INFO [Caesium-1-2] [synchrony.service.http.SynchronyRequestExecutor] execute Initiating Locking API request: SynchronyUnlockRequest
2022-01-16 18:12:25,895 INFO [Caesium-1-2] [synchrony.service.http.SynchronyRequestExecutor] execute Initiating Locking API request: SynchronyLockRequest

A Synchrony change log is eligible to be cleaned up by the soft eviction job if:

• The Synchrony change log for a page / blog has not been modified in the past three days.
• The page or blog post has no active editing sessions (no-one has this page open in the editor). 

There should be virtually no impact to end-users, because Confluence auto-saves changes regularly, and the job will ignore any pages and blog posts with an active editing session.

However, if the last person in a collaborative editing session left the editor, and changes weren't auto-saved (for example if their browser crashes), any changes between the last auto-save and leaving the editor will be lost when data is evicted. 

Hard eviction job

This job is disabled by default. It can be run manually, or you can schedule it to run periodically if required. 

This job will evict the synchrony data for any page or blog post that is older than 15 days.  For example, if a page was created more than 15 days ago, and subsequently edited every day after that, all synchrony data associated with the page would be evicted by the hard eviction job. This particular page would not be eligible to be cleaned up by the soft eviction job, because it was edited within the last three days of each time the job ran. 

The hard eviction job guarantees there is no synchrony data older than 15 days in your database, which is particularly useful if you need to remove personally identifiable information from Synchrony, or you want to reduce the amount of data in the Synchrony tables more aggressively than the soft removal job does. 

There may be some impact to end-users:

• People currently in the editor when the job runs will see an error prompting them to copy their changes and refresh. The editor will be read-only until the page is refreshed. This is similar to the behaviour when Confluence can't connect to Synchrony. 
• People who left the editor and their changes weren't auto-saved (for example if their browser crashes), may lose any changes between the last auto-save, and the point that the job is run. 

Depending on the size of your Synchrony tables, this job can take a long time, and have a noticeable performance impact, if it has not been run for some time. If you plan to schedule this job to run regularly, consider manually truncating the Synchrony tables first, to avoid any performance issues the first time it runs. This isn't necessary the first time you upgrade to a Confluence 7.x version, as an upgrade task will truncate these tables for you. 

Changing the job behaviour

In the Scheduled Jobs screen you can run a job manually, change what time, or how frequently it should run.  See Scheduled Jobs for more information. 

You can also change the default behaviour of these scheduled jobs using system properties. In most cases the default values will be adequate. For example, you could:

• set the synchrony.eviction.soft.job.threshold.hours  system property to to change the soft eviction job to only clean up Synchrony change logs that have not been modified for 7 days, instead of 3 days.
• set the synchrony.eviction.hard.job.threshold.hours system property to change the hard eviction job to remove data for any page that has edits from 20 days ago or earlier, instead of 15 days. 

See Recognized System Properties for details of all the system properties that apply to these jobs. 

Removing Synchrony data manually

If you're using Confluence 6.x, or you need to delete all Synchrony data at once (not gradually using the scheduled jobs) you can choose to truncate the Synchrony database tables.

See How to reduce the size of Synchrony tables for more information. As always, we recommend taking a full backup of your database before making changes directly on your database.