Feat/transaction interceptor framework#143
Open
Aamir377300 wants to merge 1 commit into
Open
Conversation
…nism Signed-off-by: Aamir377300 <belalaamirkhan@gmail.com>
Aamir377300
force-pushed
the
feat/transaction-interceptor-framework
branch
from
8bb5414 to
3b4513b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pr resolve issue #141
Description
This PR introduces a TransactionInterceptor framework for the Hiero Enterprise Java SDK to provide a centralized way to handle transaction execution concerns such as retries, logging, and tracing.
While exploring the transaction flow, I noticed that retry handling for temporary failures currently needs to be implemented manually by applications. In scenarios where a node is temporarily
BUSYor unavailable for a short time, developers may end up repeating similar retry logic across services.To improve this, this PR adds a middleware/interceptor-style execution layer around transaction.execute().
Changes Included
Added a TransactionInterceptor abstraction
Introduced interceptor chain support in ProtocolLayerClientImpl
Added ExponentialBackoffRetryInterceptor for handling transient failures such as:
Added MicroProfile/CDI integration using:
and kept the design extensible so additional behaviors like metrics, tracing, or auditing can be added easily
Why This Change
This helps provide a shared and reusable resilience layer instead of requiring retry handling in multiple places throughout an application.
It also makes the transaction pipeline more extensible for enterprise use cases.
Verification
Verified successful project build with:
and tested interceptor registration and execution flow in ProtocolLayerClientImpl
I’d appreciate any feedback or suggestions on the approach and implementation. Thanks for reviewing!