|
Hello Richard, Sunday, October 15, 2000, 8:15:08 AM, you wrote: > Ladies and gentlemen: > Please beware of this technique in a very high-volume situation - it will > work most of the time but it is a problem in high volume. Richard, when you use the technique as I described with locking the data area etc you should not have any trouble in a high volume situation. This is because only one job is going to be able to lock the data area and the changed data is flushed to disk prior to the lock being released. Then the next job that is waiting on the lock will be able to acquire the lock and do the same... Each time the trigger flushes the data area and explicitly unlocks it. Or at least that is my understanding ( I think this has been the behavior for as long as data areas have existed ). I have been using this technique for quite some time and I have added more than 400 records per second in some tests of a very simple trigger that just auto incremented the integer key of the table. Thanks Eric +--- | This is the RPG/400 Mailing List! | To submit a new message, send your mail to RPG400-L@midrange.com. | To subscribe to this list send email to RPG400-L-SUB@midrange.com. | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.