Hi.

We have deadlocks involving DELETEs, and I was hoping that
DB2_SKIPDELETED might be able to help in the short term.

I was looking at the following link:

"http://publib.boulder.ibm.com/infocenter/cmgmt/v8r3m0/index.jsp?topic=/com.ibm.cmgmtreadmefp.doc/d104742.htm"

It states that:

db2set DB2_EVALUNCOMMITTED=ON
db2set DB2_SKIPINSERTED=ON
db2set DB2_SKIPDELETED=ON

(specifically DB2_SKIPDELETED) are variables which can protect from
locking in some cases.

Is this intended to protect a SELECT from deadlocking against a DELETE?

And do you know which versions of DB2 have these variables available?

Any help would be much appreciated.

Joel

<misterutterbag@yahoo.com> wrote in message
news:1169125922.869409.188010@v45g2000cwv.googlegr oups.com...
> Hi.
>
> We have deadlocks involving DELETEs, and I was hoping that
> DB2_SKIPDELETED might be able to help in the short term.
>
> I was looking at the following link:
>
> "http://publib.boulder.ibm.com/infocenter/cmgmt/v8r3m0/index.jsp?topic=/com.ibm.cmgmtreadmefp.doc/d104742.htm"
>
> It states that:
>
> db2set DB2_EVALUNCOMMITTED=ON
> db2set DB2_SKIPINSERTED=ON
> db2set DB2_SKIPDELETED=ON
>
> (specifically DB2_SKIPDELETED) are variables which can protect from
> locking in some cases.
>
> Is this intended to protect a SELECT from deadlocking against a DELETE?
>
> And do you know which versions of DB2 have these variables available?
>
> Any help would be much appreciated.
>
> Joel

It takes two different applications, each locking on two different objects
to cause a deadlock (usually from two different SQL statements).

With DB2_SKIPDELETED=ON, if a row is deleted by application program 1, then
application program 2 will assume the row does not exist (and will not
lockwait on that row) even if application 1 has not committed the delete.

I believe DB2_SKIPDELETED=ON was introduced in 8.1 FP 4.