[fix](editlog) Fix BDBJEJournal.write() burning journal IDs on failure

[dataroaring]

Summary

• Both single-item write() and batch write() call nextJournalId.getAndIncrement() / getAndAdd() before the actual BDB put/commit
• If the write fails (e.g. ReplicaWriteException, InsufficientAcksException), the journal IDs are permanently consumed but no journal entry exists
• On retry, the write uses a new ID, creating gaps in the journal ID sequence
• These gaps can confuse the replayer which expects contiguous journal IDs
• Fix: read the current ID with get() before writing, advance with incrementAndGet() / addAndGet() only after successful commit. Both write methods are synchronized, so the pattern is safe.

Test plan

• Verify journal IDs remain contiguous after transient write failures
• Verify replayer correctly replays all journals without gaps

🤖 Generated with Claude Code

[Thearas]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[Copilot]

Pull request overview

Fixes journal ID gaps by only advancing nextJournalId after a successful BDBJE put/commit, preventing “burned” IDs on transient write failures that confuse the replayer.

Changes:

• Batch write(JournalBatch) now reads nextJournalId with get() and advances via addAndGet() only after a successful transaction commit.
• Single-item write(short, Writable) now reads nextJournalId with get() and advances via incrementAndGet() only after a successful put.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

nextJournalId.addAndGet(entitySize) is performed inside the retry loop. This is safe only if the method exits/breaks immediately after a successful commit; otherwise a future refactor (or a subtle control-flow change) could advance the counter multiple times for the same batch. To make this robust, consider structuring the success path to return/break immediately after txn.commit() (and then advance once), or perform the addAndGet in a single place that is executed exactly once when writeSucceed is finalized.

[Copilot]

nextJournalId.addAndGet(entitySize) is performed inside the retry loop. This is safe only if the method exits/breaks immediately after a successful commit; otherwise a future refactor (or a subtle control-flow change) could advance the counter multiple times for the same batch. To make this robust, consider structuring the success path to return/break immediately after txn.commit() (and then advance once), or perform the addAndGet in a single place that is executed exactly once when writeSucceed is finalized.

[Copilot]

The comment says “Reserve ID only after successful write”, but the code still selects the ID before the write; what changes is when nextJournalId is advanced. Consider rewording to something like “Advance nextJournalId only after successful write/commit” to match the actual behavior and avoid confusion for future maintainers.

Suggested change

	// id is the key. Reserve ID only after successful write to avoid burning IDs on failure.
	// This is safe because the method is synchronized.
	// id is the key. We advance nextJournalId only after successful write/commit
	// to avoid burning IDs on failure. This is safe because the method is synchronized.