Could someone please clarify how Cursor storage
and uncommitted Transaction storage interact with
each other?
We are using the ECPG interface to 7.2.1 on
RedHat Linux 7.2, to whatever extent that affects
the answer to this set of questions.
....
OUR APPLICATIONS
[RW-APP: Read-Write Application]
There is an always-running Application Process with a
fe-be session performing inserts and updates
[RO-APP: Read-Only Application]
There is another infrequently started Application
Process that every once in awhile makes another
fe-be session. This Application scans through the
DB by opening Cursors on various parts of the DB,
fetching from the Cursors, closing the Cursors, then
closing its fe-be session and exiting.
.....
It is our understanding that Transactions will see to
it that RO-APP Cursor opens will see only whatever
RW-APP most recently committed prior to the time
RO-APP opens its Cursor, because uncommitted
RW-APP Transactions are held in session-specific
storage pending RW-APP performing a commit or
a rollback.
The design of RO-APP expects and allows for this.
......
Our questions come from the fact that it is unclear to
us just exactly how open Cursor storage interacts
with uncommitted Transaction storage?
QUESTION 1:
Should RO-APP be doing anything other than closing
the Cursors, to tell the Engine to just 'cleanup' when
RO-APP is about to close its fe-be session and exit?
QUESTION 2:
Will an attempt by the RW-APP to do a commit or rollback
while the RO-APP is fetching through an open Cursor cause
RW-APP to wait until RO-APP closes the Cursor?
QUESTION 3:
Will an attempt by the RO-APP to open a Cursor while
the RW-APP is performing a commit or rollback cause
RO-APP to wait until RW-APP finishes its commit/
rollback?
....
Thanks for reading such a long question.
