EMF makes it remarkably easy to define structured models and work with them as Java object graphs. But what happens when those models become too important — or too large — to live only in memory or in local files? What if several users need to work on them concurrently, changes need to be transactional, history must be preserved, or different versions of a model need to evolve in parallel?
This is where CDO comes in.
CDO turns EMF models into shared, transactional, versioned data. Applications continue to work with familiar EObjects, while CDO provides repository persistence, transactions, change notifications, versioning, branching, merging, and scalable client/server access underneath.
With CDO 4.36, much of the work happened below the surface. Transactions have become safer and more flexible, large database commits can be considerably more efficient, PostgreSQL support has been thoroughly requalified, and the underlying Net4j communication layer received a substantial robustness and security overhaul.
But there is also a new API that is immediately visible to application developers.
Nested Transaction Scopes
Sometimes a larger operation consists of smaller operations that should succeed or fail independently, without immediately committing anything to the repository.
CDO 4.36 introduces nested transaction scopes for exactly this purpose:
Scopes can be nested arbitrarily. Committing an inner scope accepts its changes into the surrounding scope, but does not commit them to the repository. The enclosing scope can still roll everything back.
And because scopes implement AutoCloseable, leaving a scope without committing it automatically rolls back its changes. This makes them a natural fit for Java's try-with-resources pattern.
For existing APIs that expect a CDOTransaction, a scope can also provide a nested transaction facade. This makes it possible to introduce scoped behavior without having to redesign existing application code around a completely new abstraction.
Safer Transactions and Merges
The same release contains extensive work on transaction and merge correctness.
A failed merge or revert operation no longer risks leaving a transaction only partially modified. CDO now plans and validates these operations before applying them, and restores the previous transaction state if applying the result fails.
Merge handling for multi-valued model features has also become considerably more sophisticated. This is especially relevant when multiple users or branches modify the same collections in different ways. CDO can now reason more accurately about the actual changes rather than relying primarily on list positions.
For an application developer, the important result is simple: complex concurrent model changes can be combined more reliably, and unsuccessful operations leave the transaction in a well-defined state.
Faster Large Database Commits
A second major focus of CDO 4.36 is database performance.
Historically, even when CDO already knew about a complete large commit, many database operations were still executed individually. CDO can now group homogeneous work across a commit and send it to JDBC in much larger batches.
This benefits many large model changes: initial imports, large collections, append-heavy workloads, and transactions modifying many objects at once.
In one PostgreSQL benchmark with 100,000 list entries, two streams of 100,000 individual database operations were reduced to approximately 100 JDBC batch executions each. The measured initial commit time dropped from roughly 20 seconds to around 14–16 seconds.
CDO 4.36 goes further for repositories using branches. Many common large changes can now be persisted without first reading and rewriting the complete existing collection.
For example, if ten elements are appended to a list containing 1,000 elements, CDO can often write just those ten new elements. The same principle is also used for several other common update patterns.
In a synthetic H2 benchmark involving 100 such lists, 1,000 logical appends previously resulted in about 101,000 rows being processed. The optimized path wrote only the 1,000 actual additions. Commit time in that benchmark dropped from approximately 1.30 seconds to 0.10 seconds.
These numbers are workload-specific benchmarks, not a promise that every CDO application suddenly becomes ten times faster. But they illustrate an important architectural improvement: many large model changes now result in database work that is much closer to the size of the actual change.
PostgreSQL, Requalified
CDO's PostgreSQL support received another less visible but important investment.
The complete PostgreSQL database test suite was run against PostgreSQL 18.6 and pgJDBC 42.7.13. Along the way, a number of accumulated compatibility, database lifecycle, schema handling, data binding, and SQL portability issues were found and corrected.
The final qualification covered 5,318 tests, including normal, auditing and branching repositories, different transport configurations, and native models. The corresponding H2 test suite remained green as well.
For users considering CDO for a new server-side application, PostgreSQL therefore remains a thoroughly tested database choice.
A More Robust Communication Layer
CDO applications normally communicate through Net4j, and CDO 4.36 includes a concentrated round of work on this foundation as well.
The changes cover security, WebSocket validation, timeout handling, connector race conditions, resource leaks, channel management, and shutdown behavior. One particularly important security improvement restricts Java object deserialization when the sending peer has not yet been established as trusted.
Most applications should never notice these mechanisms directly — which is exactly the point. A communication framework is at its best when failure handling, cleanup, concurrency and security remain invisible to application code.
Digging Deeper
Existing CDO users who want the implementation details can find them in the corresponding GitHub issues:
The complete list of changes is available in the CDO 4.36 release notes.
CDO 4.36 does not try to reinvent what CDO is. Instead, it strengthens the properties that become increasingly important as an EMF application grows from a model editor into a collaborative, data-intensive system: safe transactions, efficient persistence, reliable concurrency, and robust communication.
If you already use CDO, this release should make demanding workloads safer and faster. If you use EMF but have never tried CDO, 4.36 may be a good reason to take another look: your application can keep working with the model objects it already knows, while CDO takes care of much of the difficult infrastructure required to turn those objects into shared, persistent, versioned data.
And with features such as nested transaction scopes, that infrastructure is becoming easier to use from ordinary Java code as well.
Posts
