Oppolzer - Informatik / Blog

If I read the comments so far correctly (and the excerpts from the IBM book),
the only valid reason for COMMITs on read only applications is to allow for
parallel running utilities. If you have ISOLATION CS and CURRENTDATA NO bind
option, there will simply be no locks on SELECT processing, so parallel updates
will not be affected. I suppose that in all the mentioned szenarios where there
were locks during SELECT processing you had a problem with ISOLATION CS and
CURRENTDATA YES (which generates locks in SELECT processing).

Kind regards

Bernd



Am 06.04.2012 01:18, schrieb W.C.:
>
> Yes, Not committing on Selects can cause problems. Our standard is
> Cursor Stability because of our data and how it is used UR is
> inappropriate. We have had had problems with lock contention and with
> thread usage caused by JAVA programs that weren't committing on read
> only applications. Even with isolation level of UR, you still have
> claimers.
>
> W.C.
>
>
>
> *From: R.C.
> *Sent:* Thursday, April 05, 2012 12:06 PM
> *To:* DB2-L@lists.idug.org
> *Subject:* [DB2-L] - Does commit in a read only SQL help?
>
> Hello Team,
>
> We have a bunch of application programs running in parallel and doing
> huge amount of processing.
>
> They are using onlu SELECTS that too with UR clause.
>
> I know a commit can release locks and claims.And also any page in
> buffer pool after a commit, gets externalized, there by making room
> for a new page..reducing chances of page thrashing.
>
> Usually people use commits in inserts and updates, but i've a feeling
> that it will help even in simple SELECT query also.
>
> Please share your thougths and experiences.
>
> Thanks!!!
>
> -----End Original Message-----
>
> -----End Original Message-----