devmadhuu commented on code in PR #7452:
URL: https://github.com/apache/ozone/pull/7452#discussion_r1856645517
##########
hadoop-ozone/recon/src/main/java/org/apache/hadoop/ozone/recon/upgrade/ReconLayoutVersionManager.java:
##########
@@ -84,26 +85,41 @@ public void
finalizeLayoutFeatures(ReconStorageContainerManagerFacade scmFacade)
List<ReconLayoutFeature> featuresToFinalize = getRegisteredFeatures();
for (ReconLayoutFeature feature : featuresToFinalize) {
- try {
- // Fetch only the FINALIZE action for the feature
- Optional<ReconUpgradeAction> action =
feature.getAction(ReconUpgradeAction.UpgradeActionType.FINALIZE);
- if (action.isPresent()) {
- // Execute the upgrade action & update the schema version in the DB
- action.get().execute(scmFacade);
- updateSchemaVersion(feature.getVersion());
- LOG.info("Feature versioned {} finalized successfully.",
feature.getVersion());
+ try (Connection connection = scmFacade.getDataSource().getConnection()) {
Review Comment:
> Since apache derby works on the principle of JDBC and derby provides a
JDBC driver that allows Java applications to interact with the database using
standard JDBC API calls.
>
> Lets consider 3 Features needed to be finalised Feature 1, 2, 3 ➖
>
> In the scenario , each feature's upgrade is managed within its own
transaction using a shared database connection (`Connection 1`). Here's how the
process unfolds:
>
> 1. **Feature 1:**
>
> * **Transaction Begins:** A new transaction starts on `Connection
1`.
> * **Execution:** Feature 1's upgrade actions are performed.
> * **Commit:** Upon successful completion, the transaction is
committed, making all changes permanent.
>
> 2. **Feature 2:**
>
> * **Transaction Begins:** A new transaction starts on the same
`Connection 1`.
> * **Execution:** Feature 2's upgrade actions are performed.
> * **Commit:** Upon success, this transaction is also committed,
persisting the changes.
>
> 3. **Feature 3:**
>
> * **Transaction Begins:** Another new transaction starts on
`Connection 1`.
> * **Execution:** Feature 3's upgrade actions are attempted.
> * **Failure:** An error occurs during execution.
> * **Rollback:** The transaction is rolled back, undoing any changes
made during Feature 3's upgrade.
>
>
> **Impact on Previous Features:**
>
> The rollback of Feature 3's transaction does **not** affect the committed
transactions of Feature 1 and Feature 2. In JDBC, each transaction is
independent. Once a transaction is committed, its changes are permanent and
isolated from subsequent transactions. Therefore, the successful upgrades and
schema changes of Features 1 and 2 remain intact, even though Feature 3's
transaction was rolled back.
>
> I have referenced this doc for the analysis ➖
>
>
https://examples.javacodegeeks.com/java-development/core-java/sql/jdbc-transaction-rollback-example/
>
> I think I agree with you @devmadhuu we might use the same connection here
for all features.
Thanks for considering it, Just one thing which you might need to be
cautious in a case when you have 3 features to upgrade and 1st is successful
commit, then 2nd is failed and you did roll back, then before using same
connection for 3rd feature upgrade, have a check if connection is not closed,
because due to failure on 2nd upgrade and rollback, there might be possibility
of connection closure in some abrupt cases, so if connection was closed, then
you can create a new connection else not. You can verify this in your test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
