D
dbeavon
Guest
Thanks for the response. That is probably what is happening but there is no KB yet for it (at least not in relation to COMPILE), and I didn't think this type of a problem would go so far as crash the entire process. So the AVM/runtime isn't that careful about using partially written r-code files? It seems like Progress should be relying on a checksum or MD5 feature - in order to avoid using an r-code file that is invalid. At a very minimum it seems like the COMPILE statement should generate an error condition instead of crashing. It would be better if the runtime would keep it together, rather than panicking and crashing out of the entire process. Or better yet, just rely on the file-system and OS to provide the concurrency control. Those r-code files can be shared for reading and exclusive for writing. It doesn't seem like this is so difficult ... a database vendor like Progress shouldn't have trouble with the concept of controlling concurrent access to a file resource. >> Should be avoidable if each worker uses the SAVE INTO option to write the r-code to it's own folder outside of the propath, and merging the outputs of the different workers into a final set when they've completed. Yes ... I'm thinking of using that approach, or giving up and using PCT one day (once it is formally supported). Building our own compiler tooling is an uphill battle for sure, despite the fact that we've been at it for twenty years. It seems like Progress has a *lot* of opportunity for improvements in this area. ABL customers lose efficiency in the creation applications if they are also burdened with the creation of our own compiler and deployment toolchains.
Continue reading...
Continue reading...