View Revisions: Issue #3005
| Summary | 0003005: SequenceFactory may issue duplicate outgoing_batch (batch_id) sequence numbers when shared db transactions are rolled back | ||
|---|---|---|---|
| Revision | 2017-03-02 22:06 by mmichalek | ||
| Description | Saw a case with 2 clients where the system was configured with an invalid initial load select. This caused the routing process to start the initial load, and then fail and rollback its db transaction. That same db transaction had been passed into SequenceFactory and (potentially) used to update the sym_sequence table for the next value of the outgoing_batch sequence. When the db transaction rolls back, so does the update to sym_sequence. These leaves SequenceFactory in a position where it may have already dispensed sequences 1-10, but be set back to sequence 1, after the db transaction rollback. This lead to side affects such as PK violations on the sym_outgoing_batch.batch_id field, and existing batches being re-opened and additional data added to them. As a resolution, SequenceFactory will now be more self contained and not participate in outside db transactions like this. |
||
| Revision | 2017-03-02 21:45 by mmichalek | ||
| Description | Saw a case with 2 clients where the system was configured with an invalid initial load select. This caused the routing process to start the initial load, and then fail and rollback its db transaction. That same db transaction had been passed into SequenceFactory and (potentially) used to update the sym_sequence table for the next value of the outgoing_batch sequence. When the db transaction rolls back, so does the update to sym_sequence. These leaves SequenceFactory in a position where it may have already dispensed sequences 1-10, but be set back to sequence 1, after the db transaction rollback. As a resolution, SequenceFactory will now be more self contained and not participate in outside db transactions like this. |
||