E
Evan Bleicher
Guest
I would like to take this opportunity to provide some context on how the Development team handled OCTA-16825, which was originally logged as a regression. As noted in this post, the ABL compile statement is a session-based facility for compiling a procedure or class file. The output of the compilation is either a single or possibly multiple rcode files. The compile statement has no synchronization with any other ABL sessions. One of the examples cited in this post, was compiling an updated source file, while the corresponding r-code file was being used in a running application. Alternatively, compilation may be occurring in one session, while another session is compiling the same project. To some degree the ability to perform these simultaneous actions is supported by OpenEdge on Unix by leveraging operation system calls. These calls allow us to write new r-code to a temporary file and then rename it to the proper name without disrupting existing readers of that same r-code file. This capability is not supported on Windows. The development team attempted to identify other approaches to provide a similar behavior on Windows and did not find a viable solution. It was also conclusively determined that the product had not regressed and in fact this behavior has always existed in the product. The decision to address this behavior (cost of development and validation) needed to be weighed against the benefit and implicitly the frequency of this situation occurring. I noted that on Unix, to some degree, these simultaneous actions are supported. But it is possible that an invalid outcome may still occur. In the scenario in which one ABL session is compiling a project while the project is being run in another session, it is possible for the running application to fail. For example, this can occur if the signature of a method is changed. If the session which is compiling the project compiles and generates a new r-code file for a class, before the calling class or procedure is recompiled, a runtime error could occur during the execution of the logic which invokes the method. For this reason, it is best practice to holistically compile a project prior to updating a running application. In fact, the Progress Application Server for OpenEdge (PASOE) environment supports the ability to easily update an application in production without impacting running agents. See “Update PROPATH in a production instance with zero downtime” ( docs.progress.com/.../Update-PROPATH-in-a-production-instance-with-zero-downtime.html). Therefore, the decision was made to invest OpenEdge Development resources on other issues as this issue can be avoided by leveraging existing development practices. However, this discussion highlighted that we need to add clarifications to documentation noting these limitations.
Continue reading...
Continue reading...