Nathan,
Certainly a user space would be a faster (and arguably more secure due to
obscurity) method of communicating but it is also somewhat more intensive to
set up and manage. Data Queues are only marginally slower and easier to
set up, program for, and manage.
That said, I really like the idea, I'll have to do some research to see how
to utilize it. The key must be in the data structure of the user space.
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Nathan Andelin
Sent: Tuesday, March 22, 2016 11:58 AM
To: Midrange Systems Technical Discussion
Subject: Re: Track all records read from a table
I agree. However, it won't help the OP with the performance hit
caused by read triggers.
Seems rather odd to me that database I/O is cached by default. But you have
to license that feature for journals.
Regarding the performance hit on read triggers, I think Jim hit the nail on
the head by suggesting an asynchronous process and using a data queue. We
use a similar process. Except we use shared memory between the trigger
program and an external JOB which we call a database event handler to pass
record buffers, which is even faster than a data queue.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
midrange.com
