Request workflow steps with ksc_store are locking

  • KM01389574
  • 04-Feb-2015
  • 04-Feb-2015


Workflow steps in a cluster are locking randomly


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(
at com.kintana.core.arch.TransactionContextImpl.lock(
at com.kintana.core.arch.TransactionContextImpl.lock(
at com.kintana.core.arch.ClientTransactionContext.lock(
at com.kintana.core.arch.BatchTransaction.setup(
at com.kintana.core.arch.BatchTransaction.setup(
at com.kintana.crt.util.RequestSaveHelper.saveRequestAdditiveInformation(

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


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


Every section in the server.conf should have


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.