I can give you a comprehensive breakdown of what’s happening and how to address it properly.
Root Cause
Windchill’s revision promotion in 11.1 M030 uses an optimistic locking strategy on the RevisionSchemeHelper.getNextRevision() method, which reads the current max revision from the REVISIONINFO table, calculates the next value, and writes it back. Under concurrent load, two transactions can read the same current revision (say ‘B’), both calculate ‘C’ as the next value, and due to the retry-on-conflict logic in WTContainerHelper, the losing transaction re-reads the table — but now finds ‘C’ already committed — and increments to ‘D’. The ‘B→D’ skip is a known artifact of this retry path.
Immediate Workarounds
- Add these properties to
wt.properties and restart MethodServer:
wt.vc.revisionLocking.mode=PESSIMISTIC
wt.vc.revisionLocking.timeout=30000
wt.vc.optimisticRetryOnRevision=false
The third property (optimisticRetryOnRevision=false) was introduced in M028 and tells the framework to throw a checked exception on collision rather than silently retrying with a stale sequence value. Users will see a ‘revision conflict’ dialog and must re-initiate check-in, which is slightly disruptive but prevents skipped levels.
- Oracle sequence cache fix — this is separate but compounds the issue. Log into Oracle and run:
SELECT sequence_name, cache_size FROM dba_sequences
WHERE sequence_name LIKE '%REVISION%';
ALTER SEQUENCE WTREVISIONINFO_SEQ NOCACHE;
A non-zero CACHE means Oracle pre-allocates sequence values; on instance restart or RAC failover, cached-but-unused values are discarded, creating gaps. NOCACHE eliminates this entirely at a minor performance cost.
- Stagger workspace check-ins — as an administrative measure, if your morning sync is predictable, you can use Windchill’s workspace promotion request queuing by enabling:
wt.vc.workspace.serializedPromotion=true
This serializes promotion requests at the container level, eliminating collisions at the cost of some throughput.
PTC Support Case
Request PTC search for SPR 2437891 and the associated M030 hotfix bundle. There is a patch that backports the M032 fix which rewrites the critical section in DefaultRevisionScheme.incrementRevision() to use a SELECT FOR UPDATE pattern on Oracle, making it inherently safe under concurrent load.
Long-term Fix
Upgrading to 11.1 M032 or later is the clean path — the revision incrementing was refactored to use database-level row locking in that release, and we have not seen a single skip incident since upgrading our 14-site deployment.
Verification
After applying the wt.properties changes, you can simulate concurrent check-ins using the Windchill Workgroup Manager test harness or a simple script that triggers two parallel CheckInHelper.service() calls on the same container. With the fix in place, one will succeed and one will get a clean conflict exception rather than silently skipping a revision.
Hope this helps — let me know what PTC support comes back with on the hotfix.
This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.