Kbase P146906: How to avoid file contention issues when multiple processes output to the same file
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
6/29/2009 |
|
Status: Verified
GOAL:
How to avoid file contention issues when multiple processes output to the same file
GOAL:
Performance issues attempting to access the same file by multiple processes
GOAL:
Errors when multiple processes write to the same file
FACT(s) (Environment):
All Supported Operating Systems
Progress 7.x
Progress 8.x
Progress 9.x
OpenEdge 10.x
FIX:
Following are a list of suggested ways to handle writing to a common output file from multiple 4GL/ABL processes:
What people generally do when they have multiple processes that need to write to the same file is to write a middleman utility to handle the actual logging.
There are three ways to handle this which come to mind...
1) The application would write the messages to a table in a commonly connected database (preferably one separate from the application database in order to avoid affecting the existing I/O) and the logging utility would read from that table and delete or archive the records it has logged.
2) The application would use Sonic to post the log messages to a queue or a topic and the logging utility could read the messages and handle the logging.
3) The application would use a Socket object to communicate with the logging utility.
The benefit of the first and second options are message persistence... The messages stand a much better chance of getting to the logging process and the logging process can read them at leisure without worry about tying up the client, waiting for a queue to write a message to the socket.
The benefits of #1 & #3 are that they are free... You already have the needed software in place and the design is quite simple.
Failure to use such a method could potentially result in errors or high contention for the same file which may cause performance issues throughout the system where the process is running. If utilizing a middleman processes to handle the output is not an option then the best recommendation would be (unless the process is writing only a single character at a time) to use the default OUTPUT TO statement without specifying UNBUFFERED.
The UNBUFFERED option causes output to be sent to the file one byte at a time and may cause data overlap to occur.