[contrueCT]

Purpose of the PR

Topling's standalone OLAP property clear still drops and recreates the same column family. The previously reported real-JNI reproduction completes the clear task, then aborts during normal shutdown. This change clears the selected table while retaining its CF handle.

Addresses the OLAP clear/close item already tracked in #3242 and the original review. The release checklist stays open. Existing Topling and recovery PRs were checked; the merged runtime integration and snapshot-recovery fix #3293 do not cover this clear path.

Main Changes

• Clear the selected OLAP table in its owning database under the store write lock.
• Retain Topling CF handles and discard the clearing thread's pending batch before committing the clear; leave other threads' leases untouched.
• Preserve the standard RocksDB drop/create path.
• Adapt OLAP test fixtures to the shared AtomicReference owner introduced by merged fix(rocksdb): make snapshot restore retryable #3293.

Verifying these changes

• Trivial rework / code cleanup without any test coverage. (No Need)
• RocksDBSessionsTest: 28 tests pass on Java 17 after rebasing onto master 87a06a9b, with no failures/errors/skips. New tests cover retained handle identity, repeated clears, pending writes outside the stored range and in an empty table, independent OLAP routing, other-table preservation, reuse and close/reopen reads.
• Whole-repository Java 17 clean compilation, editorconfig formatting and git diff --check pass.

These tests run the Topling Java branch with the real standard RocksDB JNI. The same handle-preservation regression fails against the original master adapter. Actual Topling JNI and its reported shutdown abort were not rerun on this macOS arm64 host; current-head Linux native qualification remains necessary.

Does this PR potentially affect the following parts?

• Dependencies
• Modify configurations
• The public API
• Other affects: standalone Topling OLAP clear and native handle lifecycle
• Nope

Documentation Status

• Doc - TODO
• Doc - Done: docs/storage-lifecycle.md documents OLAP clear, handle retention and pending-write handling.
• Doc - No Need

Conceptual overview

Topling OLAP clear 保留 CF handle，标准 RocksDB 仍走 drop/create，实际 Topling JNI 验收仍需完成。

Conceptual illustration; not test or release-acceptance evidence.

English conceptual overview

Concept illustration of the Topling OLAP clear path: reset the clearing thread's pending batch, clear the selected table in its owning database, and retain the CF handle. Standard RocksDB retains drop/create; actual Topling JNI qualification remains required.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 41.71%. Comparing base (87a06a9) to head (34cc360).

Files with missing lines	Patch %	Lines
.../hugegraph/backend/store/rocksdb/RocksDBStore.java	0.00%	16 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #3299      +/-   ##
============================================
- Coverage     41.92%   41.71%   -0.22%     
+ Complexity     7101     7037      -64     
============================================
  Files           770      762       -8     
  Lines         67320    67066     -254     
  Branches       9042     9022      -20     
============================================
- Hits          28226    27974     -252     
- Misses        35879    35880       +1     
+ Partials       3215     3212       -3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bitflicker64]

Blocking: no. Summary: The Topling branch clears the selected OLAP table through the existing RocksDBSessions.clearTables path under the store write lock, with balanced useSession/close and the standard drop/create path unchanged; no correctness defect found in the Java change, two small test-coverage notes inline. Real Topling JNI shutdown behaviour was not exercised by this review or by CI. Evidence: read the full diff at 34cc360 against merge base 87a06a9 plus RocksDBStore, RocksDBSessions.clearTables, BackendSessionPool, RocksDBStdSessions.StdSession and the callers (GraphTransaction.clearOlapPk, OlapPropertyKeyClearJob); RocksDBSstStore does not inherit clearOlapTable so the SST backend is unaffected; CI job build-server / server_memory (Java 17) ran UnitTestSuite at this head: 999 tests, 0 failures, 0 errors.

[bitflicker64]

Minor: on the standard branch this assertion only proves recreation for the first clear. handle is read once before the loop (line 356) and never refreshed, so on the second iteration it is still the pre-first-clear handle and assertNotSame passes even if the second clearOlapTable did not drop and recreate the table. Please re-read the handle at the end of each iteration (for example handle = handles.get(table) after the assertions on the standard branch) so the repeated clear is actually checked.

[bitflicker64]

Minor: the reset is limited to the clearing thread's session, and the PR description states that other threads' leases are left untouched, but assertOlapClear only writes pending data from the same thread that calls clearOlapTable. Nothing pins what happens to a batch another thread has already filled for this table: RocksDBSessions.clearTables only range-deletes committed keys, so that batch commits after the write lock is released and its rows survive the clear, unlike truncate(), which calls forceResetSessions on every database. Please add a test that puts to the OLAP table from a second thread, runs the clear, commits on the second thread and asserts the intended outcome, and state that outcome in docs/storage-lifecycle.md.