fix(db): resolve resource leakage in database close()

[warku123]

What does this PR do?

Fix resource leakage in CheckPointV2Store.close() and TronDatabase.close() by ensuring dbSource.closeDB() is always executed, even when writeOptions.close() throws an exception.

Changes:

• TronDatabase.close(): Split the single try-catch block into two independent try-catch blocks for writeOptions.close() and dbSource.closeDB(), so that a failure in one does not prevent the other from executing.
• CheckPointV2Store.close(): Close the subclass-specific writeOptions first, then delegate to super.close() for parent resource cleanup, removing duplicated close logic and logging.
• CheckPointV2StoreTest: Add two test cases:
  • testCloseReleasesAllResources — verifies that dbSource.closeDB() is called during normal close.
  • testCloseDbSourceWhenWriteOptionsThrows — mocks both child and parent writeOptions.close() to throw exceptions, then verifies dbSource.closeDB() is still called.

Why are these changes required?

Previously, writeOptions.close() and dbSource.closeDB() were in the same try block in both TronDatabase.close() and CheckPointV2Store.close(). If writeOptions.close() threw an exception, dbSource.closeDB() would be skipped, causing the underlying database (LevelDB/RocksDB) to remain open and leak native resources. This is particularly problematic in environments where multiple database instances are created and destroyed.

This PR has been tested by:

• Unit Tests (CheckPointV2StoreTest — both happy path and exception scenario)
• Manual Testing

Follow up

N/A

Extra details

This is a revised version of #6621, addressing all review feedback:

• Fixed the root cause in TronDatabase.close() (parent class), not just the subclass
• Tests now cover the actual bug scenario (writeOptions throwing exceptions)
• Tests verify dbSource.closeDB() is called, which is the core guarantee of this fix
• Removed vacuous assertions, duplicate close calls in finally blocks, and redundant Javadoc

[alan-eth]

The fix for splitting the try-catch blocks is clean and directly addresses the root cause — really nice work isolating each resource cleanup independently!

One small thing: the "End to close" log moved from a finally block to a bare statement after both try-catch blocks. In the (admittedly rare) event that an unchecked Error (e.g. OutOfMemoryError) escapes from dbSource.closeDB(), this line won't execute — whereas the original finally guaranteed it would. Would it be worth wrapping both try-catch blocks in an outer try-finally?

try {
  try { writeOptions.close(); } catch (Exception e) { ... }
  try { dbSource.closeDB(); } catch (Exception e) { ... }
} finally {
  logger.info("******** End to close {}. ********", getName());
}

[warku123]

Thanks for the suggestion! Good catch on the Error case. I've moved the log into a finally on the second try-catch block instead of adding an outer try-finally — same guarantee, slightly less nesting. Updated in bcb7c0b.

[alan-eth]

Nice, putting the log in the second finally is a clean alternative — less nesting with the same guarantee. Looks good!

[halibobo1205]

[[SHOULD]]CheckPointV2Store.close() previously logged at debug on purpose — SnapshotManager.createCheckpoint() opens/closes one on every checkpoint flush. Delegating to super.close() promotes those lines to info and will spam logs.

Suggest a protected doClose() hook in the parent so the subclass can keep its debug level without duplicating logs:

// TronDatabase
@Override
public void close() {
  logger.info("******** Begin to close {}. ********", getName());
  doClose();
  logger.info("******** End to close {}. ********", getName());
}

protected void doClose() {
  try { writeOptions.close(); }
 catch (Exception e) { logger.warn("Failed to close writeOptions in {}.", getName(), e); }
  try { dbSource.closeDB(); }
  catch (Exception e) { logger.warn("Failed to close dbSource in {}.", getName(), e); }
}

// CheckPointV2Store
@Override
public void close() {
  logger.debug("******** Begin to close {}. ********", getName());
  try { writeOptions.close(); }
  catch (Exception e) { logger.warn("Failed to close writeOptions in {}.", getName(), e); }
  doClose();
  logger.debug("******** End to close {}. ********", getName());
}

[warku123]

Good catch! Implemented the doClose() hook in 39cddb5 — CheckPointV2Store.close() now logs at debug level and calls doClose() directly, so high-frequency checkpoint flushes won't spam the info log.