# Release Notes

version 3.16.0

## Overview

SymmetricDS 3.16 release includes 0 features, 0 improvements, and 0 bug fixes.

## What’s New

### Channel Improvements

Internal operational SYM tables, such as node, node_security, and incoming/outgoing_error, now use a "system" channel so they act independently and are easier to see as batches for operations versus configuration changes (on the "config" channel). All SYM tables are using channels with a "system" queue so they sync on their own thread even when other channels have a backlog. The "reload" channel for initial and partial loads now defaults to the "bulk" data loader with an increased max batch size of 100,000.

### Ready Queues

Ready queues is a feature to make efficient use of multiple queues and their associated threads. Instead of each node communication thread querying for ready data, the cache manager now keeps a list of queues by node that are ready with changes to send, reducing the number of queries needed. Push and pull service use the ready queues to efficiently allocate only the threads needed to send or receive data. Since pull service runs on the target, it still contacts each node on the default queue to get a list of ready queues.

### Faster Local Data Transfer

When engines are hosted together (by placing the engine files in the same "engines" directory), a batch for a target engine will be accessed from the source engine’s staging area directly instead of copying it, saving the I/O cost of copying the data again. Remote nodes are unaffected and still receive batches over the network as usual.

### Technology Upgrades

H2 database version 2.2 is now included. Users with existing H2 1.x databases may need to add ";MODE=LEGACY" to the end of db.url or "set MODE LEGACY" to db.init.sql (the Pro installer will do this automatically). Users with existing H2 2.0 or 2.1 databases need to export their database from the old version and import into the new one (the Pro installer will do this automatically). The server property of server.http.cookies.enabled is now true by default to accept cookies used by load balancers.

## Tables

The following changes were made to the definition of configuration and runtime tables. Table changes are applied to the database automatically using data definition language (DDL) during startup.

### New Columns

SYM_EXTRACT_REQUEST
Column Name | Description
--- | ---
`extract_thread_id` | Thread number within dynamic queue assigned for extraction
`load_thread_id` | Thread number within dynamic queue assigned for loading over push/pull
`bulk_rows_loaded` | The number of rows that are bulk loaded in an extract.

SYM_NODE_GROUP_LINK
Column Name | Description
--- | ---
`sync_sql_enabled` | Whether SQL/DDL events are routed and synced on this link.

SYM_NODE_SECURITY
Column Name | Description
--- | ---
`partial_load_time` | The timestamp when a partial load was started for this node.
`partial_load_end_time` | The timestamp when a partial load was completed for this node.
`partial_load_id` | A reference to the load_id in outgoing_batch for the last partial load that occurred.
`partial_load_create_by` | The user that created the partial load. A null value means that the system created the batch.

SYM_OUTGOING_BATCH
Column Name | Description
--- | ---
`thread_id` | Thread number within dynamic queue assigned for loading over push/pull

SYM_TABLE_RELOAD_STATUS
Column Name | Description
--- | ---
`row_bulk_load_count` | The number of rows that were loaded with the bulk loader.

## Parameters

The following changes were made to add new parameters, modify their default value, modify their description, or remove them from use.

### New Parameters

auto.resolve.capture.delete.missing.rows

If this is true, when a delete affects zero rows, if the table is configured for sync on incoming, then the auto resolver will write the deletes into the capture log. (Default: false)

cache.ready.queue.time.ms

This is the amount of time ready queue entries will be cached before re-reading them from the database. (Default: 5000)

create.table.include.application.triggers

If set to true, when a table’s schema is sent to the target database it will also send the DDL script that will create an application trigger at the target if the source and the target database types are the same. SymmetricDS trigger DDL statements will not be sent. (Default: false)

dataloader.sql.event.strip.comments

Enables removal of block comments from script text by data loader processing DDLs. Applies to stores procedures and functions, when DDL replication is enabled. (Default: true)

incoming.batches.use.source.staging

If source and target engine are hosted together, the source will send a "retry" command instead of sending the batch, and the target will use the source’s outgoing staging to access the batch. This also requires the staging to be enabled (stream.to.file.enabled=true). (Default: true)

initial.load.defer.table.logging

If tables are created as part of the initial load, it will defer setting up table-level logging to improve performance. Applies to loads only. After data is loaded, the table-level logging will be switched on. This parameter needs set for the node that will send the initial load, not the node receiving it. Support for table-level logging varies by database dialect and is ignored where not applicable. Currently this is only supported by the PostgreSQL UNLOGGED feature. Oracle’s NOLOGGING feature might be implemented in the future. Note: this parameter is not compatible with PostgreSQL tables referenced by foreign keys. (Default: false)

initial.load.extract.max.process.time.ms

The number of milliseconds that the initial load extract job can run a thread for processing extracting requests. (Default: 3600000)

sync.use.ready.queues

Whether push and pull should use ready queues to limit queries and communication. Ready queues is the list of queues with outgoing batches that are ready to be sent, queried periodically and cached. When enabled, the pull service first pulls the default queue and receives a list of ready queues that should also be pulled, instead of pulling those queues every time. The push service gets the list of ready queues to allocate threads for calling data extractor service. (Default: true)

### Modified Parameters

outgoing.batches.copy.to.incoming.staging

When sending an outgoing batch, copy directly from the outgoing staging to the incoming staging when both nodes are on the same server. This also requires the staging to be enabled (stream.to.file.enabled=true). The HTTP transport is still used to send a batch "retry" instruction that causes the target node to read from staging. Deprecated and replaced by incoming.batches.use.source.staging. (Old Default: true) (New Default: false)

routing.use.channel.threads

When enabled, use a thread per channel for parallel routing. (Old Default: false) (New Default: true)