nzw921rx commented on PR #10678: URL: https://github.com/apache/seatunnel/pull/10678#issuecomment-5276889154
I think there may be another direction worth discussing further: while continuing the current cleanup work, could we also gradually define a **complete ClassLoader lifecycle model**? `DefaultClassLoaderService` already has caching and reference counting, but `getClassLoader()` / `releaseClassLoader()` still behave more like a caller-side convention. For scenarios such as job creation, restore/redeployment, abnormal termination, and sharing under `cacheMode`, the ClassLoader ownership model, acquire/release boundaries, and final close conditions are not yet expressed in a unified way. I would prefer to first establish an explicit lifecycle model. There are certainly more details than the points below, but I think we can at least start the discussion from these core stages: 1. **Acquire / Ownership**: Define who acquires and owns the ClassLoader, and what ownership is represented by each acquire operation. 2. **Use / Scope**: Define the Job / execution / task lifecycle scopes in which the ClassLoader may be used, and how ownership changes during restore or redeployment. 3. **Release**: Define unified and idempotent release semantics so that normal completion, failure, cancellation, and cleanup from an old execution can all converge safely. 4. **Resource Cleanup / Close**: After ownership is released, clean up related resources such as TCCL, JDBC Drivers, and background threads according to well-defined lifecycle boundaries, and then perform `URLClassLoader.close()`. 5. **Reclamation / Verification**: Define how we determine that the lifecycle has truly ended and verify that the old ClassLoader is no longer retained by the runtime or residual resources. These are only a few core aspects of the lifecycle model; the actual design will likely need to cover more runtime scenarios and boundary conditions. I think this is better suited as a long-term evolution track. The new lifecycle-management mechanism could first be introduced incrementally under `@Experimental`, allowing us to validate the ownership, release, and cleanup model while minimizing changes to existing behavior. Once the lifecycle semantics and runtime behavior become stable, we can then consider how to converge it with the existing implementation. If the ownership model and lifecycle contract can be clearly defined first, resources such as TCCL, JDBC Drivers, and background threads should be able to clean themselves up at their respective lifecycle boundaries. At that point, we can also reevaluate whether the current deep-clean mechanism still needs to remain as a long-term solution. -- 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]
