from DB2 v10 manual on RELEASE option of BIND, we can see:
Quote:
( COMMIT )
Releases resources at each commit point.
DEALLOCATE
Releases resources only when the program terminates.
for my instance: I have a transaction which links 4 programs sequentially, and I have declared a FOR UPDATE cursor in the 1st program. if a ' OPEN CURSOR' is executed in the 1st program, but no 'CLOSE CURSOR' executes when the 1st program ends, in the 2nd program, does the row locked by the CURSOR still locked ?
in the 4th program, I executes 'EXEC CICS SYNCPOINT ', and nowhere else issue SYNCPOINT command. There is no 'COMMIT' statement in all of these 4 programs.
more specifically speaking, a transaction invokes pgm-m,
and pgm-m links pgm-a, pgm-b, pgm-c sequentially.
pgm-a declared a FOR UPDATE cursor, OPEN it , but no CLOSE
pgm-b wants to update the row which is candidate of the CURSOR declared in pgm-a , but not sure whether the lock on the row has been released by pgm-a or not.
Joined: 20 Oct 2006 Posts: 6966 Location: porcelain throne
ok,
unfortunately a cursor must be open/closed/fetched-updated-inserted-deleted
by the declaring module.
so, pgm-b can not update the cursor declared/opened in pgm-a.
if pgm-b is to update a row within a table, that row possibly being part of the result set of pgm-a's cursor,
do a singleton update on the row in pgm-b.
if we are taking about inserts or deletes keep in mind that you now enter the problems of sensitive cursors.
but presumably you are updating a row that you have fetched,
so unless you fetch the same row again in pgm-a,
you will not see the results of the update by pgm-b.
now, if you would learn your fundamentals:
a lock is used to prevent other TASKS from modifying your data,
and pgm-b is in the same task as pgm-a,
so any locks that pgm-a has caused to be issued,
do not affect pgm-b,
since it is in the same task.....
dejunzhu,
nearly every question you pose in this forum is due
to lack understanding fundamentals.
don't make things so complicated.
