Creating and Configuring Repositories

Author: Eike Stepper

A repository has a stable name within its container, a configured store, repository properties, optional initial package definitions, and a lifecycle. The application chooses a store and properties, creates the repository, applies initial packages before activation, and registers it in the owning IManagedContainer. CDOServerUtil.addRepository(IManagedContainer, IRepository) retains and activates it; the container owns its shutdown. The store determines persistence and capabilities, while XML/server configuration composes the same pieces declaratively. Production XML and database operation syntax are described by Configuring Repositories.

1  Programmatic Repository Setup

CDOServerUtil.createRepository(String, IStore, Map) creates an inactive repository from its container name, store and property map. The name is the lookup identity within that container and should remain stable for configuration and client connection. Properties configure repository behavior such as auditing, branching, locking and ID generation; use IRepository.Props constants and confirm that the selected store supports the requested feature. Set initial packages before activation when model metadata must be available from startup. Otherwise package registration is governed by repository mode and security policy.

CDOServerUtil.addRepository(IManagedContainer, IRepository) assigns the container when needed, retains the repository under the repository-factory group/type/name, and activates it. That transfers lifecycle ownership to the container. A repository that is never registered must be explicitly deactivated by its creator if it was activated separately. At shutdown, stop extensions that use the repository and then deactivate the owning container. Capability checks should use the repository's advertised information; do not infer support from a requested property alone.

2  MEMStore and Embedded Repositories

MEMStoreUtil is suitable for an in-memory repository used by an embedded application, test, or short-lived service. Its model data is not a durable substitute for a persistent store. CDOEmbeddedRepositoryConfig is the higher-level embedded-server API: subclasses provide a store, properties, and optional initial packages, and can open a local client session. Its activation manages the embedded repository and JVM acceptor lifecycle. Use direct repository APIs when the application already owns container and transport assembly; use embedded configuration when it wants that complete local-server lifecycle packaged together. An embedded convenience API can own the repository/container and optionally open a local client session; direct APIs are appropriate when the application already owns those boundaries.

	WithMemoryRepository.java
IManagedContainer container = ContainerUtil.createInitializedContainer(); try {   IStore store = MEMStoreUtil.createMEMStore();   Map<String, String> properties = new HashMap<>();   properties.put(IRepository.Props.OVERRIDE_UUID, repositoryUUID);   IRepository repository = CDOServerUtil.createRepository("inventory", store, properties);   if (initialPackages.length != 0)   {     repository.setInitialPackages(initialPackages);   }   CDOServerUtil.addRepository(container, repository);   operation.accept(repository); } finally {   container.deactivate(); }

3  Existing Persistent Stores

A persistent store changes how the IStore is created and configured, not the repository registration lifecycle. Configure the selected DB adapter, datasource, and mapping strategy through application setup or the server XML store element, then pass the resulting store to createRepository (or let the repository configurator do so). Repository properties still describe repository behavior; store configuration describes persistence. Database installation, credentials, schema operation, and tuning remain Operator's Guide concerns. Do not implement a store merely to customize repository behavior; use handlers and services instead.