You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add nested transaction scopes and transaction facades #192
Introduce lightweight, stack-disciplined nested transaction scopes for CDOTransaction.
A new CDOTransactionScope models a nested transactional lifecycle without creating a separate view, object graph, object cache, or isolated transaction state. Scopes operate directly on the same underlying root transaction state and can be nested arbitrarily:
CDOTransaction.openScope() opens a new innermost scope.
CDOTransactionScope.openScope() opens an inner scope.
commit() accepts a scope's changes into its outer scope or root transaction without committing to the repository.
Only the innermost scope may commit.
rollback() and close() cascade through all still-open inner scopes.
Root rollback cascades through open scopes, while root commit is rejected as long as scopes remain open.
Rolling back to an older public savepoint closes scopes whose history is discarded by that rollback.
AutoCloseable support makes uncommitted scopes automatically roll back in try-with-resources.
Scopes expose outer/inner navigation, depth, and outermost/innermost transaction access.
Scope lifecycle is transaction-bound rather than thread-bound and uses the existing transaction synchronization for atomic state transitions.
Nested scope commit is deliberately different from a repository commit. It is an O(1) structural acceptance operation: the scope is closed, but its retained transaction history remains part of the enclosing transaction. No segment maps are merged or copied, no history ownership is rewritten, no repository CommitRequest is sent, and no new repository commit epoch is started. Consequently, changes accepted from a committed child scope can still be rolled back by an enclosing scope, by a public savepoint rollback, or by the root transaction.
Only a root transaction commit persists the effective transaction state to the repository and establishes a new repository baseline. Object ID representation before that commit remains dependent on the configured ID strategy; in particular, a NEW object is not required to have a temporary-form ID in every supported configuration.
Add immutable post-state lifecycle events emitted by the owning CDOTransaction:
CDOTransactionScopeOpenedEvent
CDOTransactionScopeClosedEvent with COMMITTED / ROLLED_BACK
Events are dispatched outside the transaction critical section while preserving transaction mutation order.
Refactor the internal savepoint/history representation into explicit linear TransactionBoundary and TransactionSegment concepts:
Public savepoints remain fixed-boundary snapshots.
Scope begin creates an invisible/internal transaction boundary inside the current repository commit epoch.
Current-inclusive internal aggregation traverses visible and invisible boundaries within the active epoch.
A successful root repository commit starts a fresh epoch and prevents committed predecessor history from leaking into active aggregation.
Scope rollback restores the transaction to its opening boundary using the same NEW/DIRTY/DETACHED, revision-delta, lifecycle-before-image, temporary-ID, and rollback infrastructure used by savepoints.
Scope commit leaves the boundary/segment history structurally intact so enclosing rollback operations can naturally traverse it.
Public savepoints and nested scopes therefore coexist without becoming the same concept. Public savepoint snapshots retain their fixed-boundary semantics even when nested or other invisible boundaries are created later. Public savepoints may be created through the root transaction while scopes are active; the nested transaction facade itself does not expose savepoint creation as a nested operation.
Add CDONestedTransaction extends CDOTransaction as an optional transaction-like facade for a scope. This allows existing APIs expecting a CDOTransaction to operate inside a nested scope without making CDOTransactionScope inherit the full CDOView contract.
CDONestedTransaction deliberately shares the containing root transaction's:
object identity and object cache;
resource set and view state;
dirty/effective transaction state;
locks;
session and repository connection.
It therefore does not provide database-style isolation or a separate transactional object graph. Changes made through the facade are immediately part of the enclosing transaction's effective state.
Repository commit operations are explicitly prohibited through the nested facade. Scope commit/rollback remain lifecycle operations of CDOTransactionScope; only the root transaction performs repository persistence.
Introduce reusable delegation infrastructure:
DelegatingCDOTransaction SPI for one-level and effective transaction unwrapping.
DelegatingCDOTransactionImpl as the common implementation for modern transaction facades.
Correct listener/event forwarding that preserves original event identity and source without duplicate delivery.
Keep the historical CDOPushTransaction as a deprecated legacy API type to preserve PDE/API compatibility. Introduce the modern CDOFileTransaction interface and internal implementation as its replacement, using the new delegation infrastructure while retaining file-backed commit and explicit repository push() semantics.
Add structured internal transaction-history diagnostics controlled by the single JVM switch:
-Dcdo.diagnostic=true
Diagnostics expose active boundaries and segments, public savepoints, invisible scope boundaries, current boundaries, aggregate summaries, lifecycle state, and structural invariant failures without changing normal transaction semantics.
The implementation must preserve existing savepoint behavior and remain compatible across supported repository modes, Native and Legacy model configurations, and supported object ID strategies.
Activity
Add nested transaction scopes and transaction facades #192
Add nested transaction scopes and transaction facades #192
Add nested transaction scopes and transaction facades #192
Add nested transaction scopes and transaction facades #192