Get packages

Forst of all, you need to find proper packages for your distribution. At this time Dinemic Framework supports:

  • Ubuntu 16.04, 16.10, 17.04 and 17.10
  • Debian Jessie and Stretch
  • Centos 7

All packages and versions you can find at our repository: Find proper version of your system and library version. Then download rpm, deb package or tarball if you want to extract it manually.

Dinemic framework is distributed in binary version with all dependencies, so it is important to find version dedicated for your distribution.

Redhat and Centos
rpm -Uvh libdinemic-VERSION.rpm
Debian and Ubuntu
dpkg -i libdinemic-VERSION.deb
tar xf libdinemic-VERSION.tar

Preparing environment

One of features of this framework is the database proxy and ORM. It handles data changes of C++ objects in your applications and transparently stores it inside database. Thus, the database engine is necessary to run your applications.

Dinemic provides two database drivers. First one is MemoryDriver, which is votaile and stores all data in RAM. The second driver is RedisDriver, which uses the Redis Server as key-value data store to save all data on local disk.

To use RedisDriver, install proper package:

Installing Redis at Debian and Ubuntu
sudo apt-get install redis-server
Installing Redis on Centos 7 and Redhat
yum install redis

Redis server should be installed on every node, that uses RedisDriver. Due to Dinemic architecture, each application node (you application instance) requires local data store, thus the Redis server.

Configuration file

Last step before creating your application is to adjust config.dinemic file with configuration for your application at each node. By default, this file is located in /etc/dinemic/ directory.

The default configuration file looks like following:

KEYRING_DIR: /etc/dinemic/keys


CHAINS: multiple

REDIS_SERVER: localhost

Each entry consists of key followed by colon, space and value. For example:


Defines verbosity of libdinemic framework. Allowed values are: none, error, info, debug, mutex. The last one allows to show all messages related to internal locks and is very verbose. The prefered loglevel is error or info.


Defines where dinemic should store keys for objects created within ORM and framework, and also where to store public keys of objects created on other nodes of network.


All variables beginning with ZEROMQ_… define parameters of autodiscovery mechanism of ZeroMQ synchronization driver. This parameters should be equal on all nodes of network to provide autodiscovery. Without this setting consistent, applications will not find each other. This setting could be used to run multiple clusters of dinemic applications inside one common network. By changing differen multicast port for each application type, it will not mix messages between each other.


Defines which driver should be used to store data on local machine for application. In version 0.1.5 possible values are: RedisDriver which uses Redis backnd and MemoryDriver which stores data in RAM.


Possible values: single, multiple. Since 19.01 this parameter allows to configure dinemic application to create single chain of all updates, when this value is set to single. This could be useful when order of changes in various objects is important. When value is set to multiple, each object mapped by dinemic will have separate chain of changes. This might make cluster startup faster, but in this configuration dinemic will not keep time order of updates in newly attached nodes.


This parameters are used to obtain connection with local redis server. The REDIS_DATABASE could be used to handle multiple applications on the same machine. Due to each application decides how database should look like, connectint multiple applications to the same database will cause data looses.