Processing documents through a variety of processes and storing the product of each in a table per process. Also running a dequeuer which checks a view to see that all processors have finished a document then it fetches the products of each step and deletes the row in each table.
At present we are only deleting the finished rows because we are trying to find the cause of a problem. When the dequeuer is running the slowest of the other processes (also the table with the smallest row count) fails to select from the table which contains it's starting document (another processes' table). Am logging each document processed. If it fails the process table row is not marked and the document is placed back in the work queue.
So far we have done:
1. Verified from the log that each of the selects that fail eventually succeeds. Which tells me that the problem is not that the row being selected from the feeder table has a problem.
2. Verified that there is no increase in lock contention during the failures.
3. Implemented the SybMessage handler to look for additional warnings or exceptions coming from the server. There are none.
This is a very active app which has the possibility of conflict, so we have designed out any possibilities for any two processes to access the same row in any table at the same time, added indexes to the extent necessary to eliminate table scans, etc. We have a feeling that there is some server parameter that needs adjusting to solve this problem.
Any ideas for a solution or further testing would be appreciated.
Jim
At present we are only deleting the finished rows because we are trying to find the cause of a problem. When the dequeuer is running the slowest of the other processes (also the table with the smallest row count) fails to select from the table which contains it's starting document (another processes' table). Am logging each document processed. If it fails the process table row is not marked and the document is placed back in the work queue.
So far we have done:
1. Verified from the log that each of the selects that fail eventually succeeds. Which tells me that the problem is not that the row being selected from the feeder table has a problem.
2. Verified that there is no increase in lock contention during the failures.
3. Implemented the SybMessage handler to look for additional warnings or exceptions coming from the server. There are none.
This is a very active app which has the possibility of conflict, so we have designed out any possibilities for any two processes to access the same row in any table at the same time, added indexes to the extent necessary to eliminate table scans, etc. We have a feeling that there is some server parameter that needs adjusting to solve this problem.
Any ideas for a solution or further testing would be appreciated.
Jim