Advanced Topics |
![]() |
This chapter collects advanced client techniques that sit between the core session, view, transaction, locking, notification, large-object, and integration topics. It focuses on controlling loading work, bounding memory and network cost, and making long-lived clients recoverable and diagnosable.
The chapter deliberately does not repeat view-provider integration, basic fetch-rule configuration, notification semantics, or ordinary session and transaction lifecycle. Those subjects are owned by Integrating with EMF and Other Frameworks, Working with Sessions, Working with Views, Working with Transactions, and Notifications and Event Handling.
Table of Contents
Modern CDO clients can configure partial loading of many-valued features with
CDOCollectionLoadingConfig. A non-null configuration enables the mode; its chunk configuration controls how many elements are materialized initially and how many are resolved around a later
indexed access. CDOCollectionLoadingConfig.ChunkConfig.NONE, CDOCollectionLoadingConfig.ChunkConfig.ALL,
and CDOCollectionLoadingConfig.ChunkConfig.INHERIT express explicit, complete, and inherited behavior.
Overrides can be associated with a package, class, or structural feature. Keep the initial and resolve sizes large enough for the application's access pattern: very small chunks reduce initial work but can turn sequential traversal into many requests. A null configuration disables modern partial collection loading. This configuration is distinct from revision prefetching: collection loading fills list elements, while revision prefetching loads target revisions.
The older CDOCollectionLoadingPolicy and the corresponding CDOSession.Options methods are deprecated compatibility APIs. New code should use the immutable configuration snapshot shown in
.
CDORevisionManager exposes a current request API for advanced applications that need explicit control over
cache and loader behavior. CDORevisionManager.Request.lookupCacheOnly() is useful for observing cache state
without causing network traffic; CDORevisionManager.Request.lookupLoaderOnly() deliberately bypasses the
cache as a lookup source; and the default cache-then-loader mode is appropriate for normal application reads.
A request can also ask for containment prefetch depth and lock-state prefetch. Prefetched revisions are placed in
the revision cache, but that does not materialize every EMF object or guarantee that later collection access is free
of network traffic. Use CDORevisionManager.containsRevision(CDOID, CDOBranchPoint) when a cache check is
enough, and avoid the deprecated overloads that expose the old boolean loading controls.
demonstrates a read-only cache probe.
A CDOUnit is a disjoint repository subtree with explicit loading semantics. Opening a unit loads its
elements in one request and keeps them loaded until the unit is closed. While open, its elements receive server
change notifications without requiring a matching change-subscription policy. Units therefore suit bounded working
sets such as a document, project, or other independently edited subtree.
Units belong to a view and cannot overlap. They are not a general replacement for lazy loading: opening a large unit
intentionally trades round trips for memory. Always close the unit when the working set is no longer needed, and
use an IProgressMonitor for an operation that can take noticeable time. See
.
For very large models, prefer a server-side query when the task is to
find candidates rather than to materialize a broad containment graph. Limit results with CDOQuery.setMaxResults(int),
bind values with CDOQuery.setParameter(String, Object), and use the asynchronous
result iterator when the result stream should not be accumulated in a list. The query language and expression
syntax are repository capabilities, so applications must select a language supported by the target repository.
Custom query languages are implemented and registered on the server as described in
Query Handlers.
For graph traversal, combine a deliberate revision prefetch depth with a collection-loading configuration and measure round trips for the actual access pattern. Avoid infinite containment prefetch and eager traversal merely to make later reads convenient. Large binary and text payloads should use the CDO large-object APIs described in Large Objects, not oversized ordinary attributes.
Net4j provides public recovering and reconnecting session configurations. A recovering configuration uses heartbeat
detection; a reconnecting configuration retries the connection to the same repository. Configure retry interval and
attempt limits according to the application's availability requirements, and observe CDOSessionRecoveryEvent
on the session when the application needs to report recovery progress.
Recovery is not a substitute for application-level transaction policy. A reconnecting session does not make an interrupted commit magically idempotent, and the application must decide how to handle dirty transactions, retries, stale UI state, and user-visible failures. Durable locks and their recovery implications remain the subject of Locking.
shows the supported configuration entry point.
Advanced transaction applications can install a conflict resolver through CDOTransaction.Options. The
public CDOMergingConflictResolver is an SPI-level customization and should be selected only when its merge
policy matches the application's conflict model; it does not eliminate the need to inspect conflicts or to test
domain-specific merge behavior. Basic conflict handling remains in Working with Transactions.
For diagnostics, start with public state: repository capabilities from CDOSession.getRepositoryInfo(), the
view branch/time and URI from CDOView, revision-cache checks, and the exception cause chain. Use
CDOView.sync() when a multi-step observation must be protected from invalidation between reads. Session and
recovery events are appropriate for operational status; they are not a replacement for application logging and
metrics. Do not depend on internal protocol, cache, or state-machine classes.
is intentionally minimal.
Reduce round trips by choosing the smallest useful combination of collection chunks, revision prefetch depth, and server-side query results. Reuse sessions and views when their branch/time and consistency requirements match, but close units and views when their working sets are no longer needed. Avoid enabling detailed subscriptions or unbounded prefetch for objects that the application will not inspect. Measure with the application's real access pattern: a setting that helps a bounded document load can hurt a broad search or a historical audit view.
Fetch-rule and feature-analyzer configuration is covered in Working with Sessions; notification traffic and adapter subscriptions are covered in Notifications and Event Handling; and LOB streaming is covered in Large Objects. This section is the compact decision guide, not a second configuration reference.