chimera.properties

#  -----------------------------------------------------------------------
#     Default values for Chimera namespace DB configuration
#  -----------------------------------------------------------------------
@DEFAULTS_HEADER@

#  ---- Chimera database name
#
chimera.db.name = chimera

#  ---- Chimera database host name
#
# See dcache.db.host for details.
#
chimera.db.host = ${dcache.db.host}

#  ---- URL of db connection
#
chimera.db.url = jdbc:postgresql://${chimera.db.host}/${chimera.db.name}?prepareThreshold=3&targetServerType=master

#  ---- Database user name
#
chimera.db.user = ${dcache.db.user}

#  ---- Database user password
#
chimera.db.password = ${dcache.db.password}

# ---- Database password file
#
chimera.db.password.file = ${dcache.db.password.file}

chimera.db.schema.changelog = org/dcache/chimera/changelog/changelog-master.xml


# ---- File attribute consistency behaviour
#
#  On new filesystem object creation in a directory the `modification` and
#  `change id` must be updated to provide a consistent, up-to-date view of the changes.
#  In highly concurrent environments such updates might create so-called 'hot inodes'
#  and serialize all updates in a single directory, thus, reducing the namespace throughput.
#
#  As such strong consistency is not always required, to improve concurrent updates to
#  a single directory this requirement can be relaxed.
#
#  The following values control parent directory attribute consistency:
#
#   strong: a creation of a filesystem object will right away update parent directory's
#           mtime, ctime, nlink and generation attributes
#
#   weak  : a creation of a filesystem object will eventually update (after 30 seconds) parent
#           directory's mtime, ctime, nlink and generation attributes. Multiple concurrent
#           modifications to a directory are aggregated into single attribute update.
#
#  soft   : same as weak, however, reading of directory attributes will take into account
#           pending attribute updates.
#
#
#  Read-write exported NFS doors SHOULD run with `strong consistency` or `soft consistency` to maintain POSIX
#  compliance. Read-only NFS doors might run with `weak consistency` if non-up-to-date directory attributes can
#  be tolerated, for example when accessing existing data, or  `soft consistency`, if up-to-date information
#  is desired, typically when seeking for newly arrived files through other doors.
#
(one-of?strong|weak|soft)chimera.attr-consistency=strong

(obsolete)chimera.db.dialect = Not used any more
(obsolete)chimera.db.jar = dCache auto-detects which driver to use
(obsolete)chimera.db.jar-when-H2 = dCache auto-detects which driver to use
(obsolete)chimera.db.jar-when-HsqlDB = dCache auto-detects which driver to use
(obsolete)chimera.db.jar-when-PgSQL = dCache auto-detects which driver to use
(obsolete)chimera.db.jar-when-PgSQL95 = dCache auto-detects which driver to use