PPM Support Tip: Request workflow steps with ksc_store are locking

[randull]

Knowledge Article: KM01389574

Error Message

One or more references in this Request is being updated by another database session. Please try again later. (KCRT-40186)

Request nnnnnn is being updated by another database session. (KNTA-10026)
at com.kintana.core.server.ServerConnectionImpl.lock(ServerConnectionImpl.java:766)
at com.kintana.core.arch.TransactionContextImpl.lock(TransactionContextImpl.java:42)
at com.kintana.core.arch.TransactionContextImpl.lock(TransactionContextImpl.java:57)
at com.kintana.core.arch.ClientTransactionContext.lock(ClientTransactionContext.java:183)
at com.kintana.core.arch.BatchTransaction.setup(BatchTransaction.java:165)
at com.kintana.core.arch.BatchTransaction.setup(BatchTransaction.java:130)
at com.kintana.crt.util.RequestSaveHelper.saveRequestAdditiveInformation(RequestSaveHelper.java:151)

And the below query returns rows under locking conditions:

select a.OBJECT_ID, a.LOCKED_MODE, c.owner, c.object_name, c.object_type, b.sid, b.serial#, b.status, b.osuser, b.machine from v$locked_object a , v$session b, dba_objects c where b.sid = a.session_id and a.object_id = c.object_id

Cause

In a cluster with multiple physical machines only had one SERVER_ENV_NAME defined.

Workaround / Fix

Every section in the server.conf should have

com.kintana.core.server.SERVER_ENV_NAME=KINTANA_SERVER_A

that points to the a PPM Environment(i.e. KINTANA_SERVER_A, KINTANA_SERVER_B, ect) where the node is running.

find all references to KINTANA_SERVER in your knta_command_steps
something like:

select * from knta_command_steps where command like '%KINTANA_SERVER%'

understand what each command is doing.  If there is no reason it should always go to the primary machine then find the command (in the front end interface not directly in DB) and change it to use the "[AS.SERVER_ENV_NAME ]" token

That way you will not get cross linked machine dependencies