Package com.saperion.common.config.manager

Class DbConfigurationManager<CommonAccessException extends Exception>

java.lang.Object
com.saperion.common.config.manager.DbConfigurationManager<CommonAccessException>
Type Parameters:
CommonAccessException - the common access exception type of the underlying DataSource and so of the DbConfigurationManager to be created.
public class DbConfigurationManager<CommonAccessException extends Exception> extends Object

The DbConfigurationManager manages configuration values in a database table and an in-memory cache.

One must specify a DataSource. One can set a different table name. One can create the table if it does not exist.

A configuration value is basically a String. There are several methods for conversion of other values to string during get() and set() and it is highly recommended to rely on these specialized get()-methods and according objects it set() and not to convert them in the business code by yourself. These classes are supported:

A configuration value can be null. This is treated as a valid value and it is a difference, whether a configuration value not exists or exists and is set to null. For Strings null and an empty String both are stored as null. All get()-methods will return null in this case. So there is (intentionally) no way to store an empty String.

A configuration value is identified by a key that is a HierarchicalName. It is highly recommended to group your configuration values according to their sense and common usage the same way as you group java-classes into packages. All configuration values that belong to the same sub-tree can be loaded together.

The get()-methods have an optional StorageType-parameter, that controls whether a configuration value should be loaded from the database, from the in-memory cache or from the database only if it is not found in the in-memory cache. The methods without the StorageType-parameter behave like StorageType.DEFAULT, i.e. they use the StorageType that was specified to use as the default during construction of the DbConfigurationManager (@see DbConfigurationManagerConstructorParameters.setDefaultStorageType(StorageType)).

Usual approaches are:

A root name can be provided in which case all entry-keys will start with this root name. If the key specified as a method parameter already starts with the root name it will be used unchanged, else the parameter will be added to the root name before use.

The configuration values can be encrypted/decrypted automatically. Simply specify a Cipher and Pair of Keys .

One can fine-tune what should happen if a requested configuration value is not found.

This DbConfigurationManager does no transaction handling. It simple executes its SQL-statements and relies on a suitable surrounding transaction management. If used in a JEE-container this is usually exactly the desired behavior. If used in a stand-alone application, one should care about the transaction around the invocations of methods of this class.

Apart from transactional aspects the methods are synchronized, so an instance of this DbConfigurationManager can be used in several threads concurrently.

Author:
agz
See Also: