Dans le cadre Oracle Service Bus, si vous utilisez le mode « Append » de l’adaptateur de fichiers (connecteur JCA), il est fort probable, qu’à la suite de traitements, vos logs vous publient cette erreur* :

####<17 janv. 2017 14 h 20 CEST> <Error> <JCA_FRAMEWORK_AND_ADAPTER>
<xxxxx> <SRVXXXX> <[ACTIVE] ExecuteThread: '30' for queue: 'weblogic.kernel.Default (self-tuning)'>
<<anonymous>> <BEA1-123A0A9D82A30C6920D4> <0000LU^F8a7AXNnawlEgMG1Nw6M_000Pxj> <1475929233197>
<BEA-000000> <servicebus:/WSDL/XXX [ Write_ptt::Write(body) ] -
Could not invoke operation 'Write' due to:
BINDING.JCA-11063
Impossible d'acquérir le mutex pour l'interaction.
Impossible d'acquérir le verrou sur la ressource
   "/share/XXX/output~SLC_%yyMMddHHmm%" pour "DatabaseMutex::acquireNoSave"
Vérifiez la pile derreurs et éliminez la cause de lerreur.
   Si vous ny parvenez pas, contactez le support Oracle.
      at oracle.tip.adapter.file.mutex.db.DatabaseMutex.acquireNoSave(DatabaseMutex.java:1144)

*: Trace synthétisée afin de mettre en évidence les lignes qui auront le plus de sens pour cet article. Il est donc possible que votre trace d’erreurs soit beaucoup plus longue.
Cela est simplement dû à un problème d’accès concurrents au verrou « mutex » système des ressources OSB. Lorsque « l’acquisition du verrou » est impossible, le traitement alors en échec est généralement relancé (le mode « retry » du « business service » doit être activé).
Pour rappel, un « mutex » est un « lock » qui ne peut avoir au maximum qu’un seul propriétaire à un instant donné, mais qui peut être partagé par plusieurs processus système. Si quelqu’un d’autre essaie d’en prendre possession, alors son exécution sera bloquée jusqu’à ce que ce soit possible.
Ce conflit de « multi-threading » peut être résolu de manière pérenne en activant un « lock » (verrou spécifique) sur le « business service » concerné à l’aide de la propriété dynamique « Oracle DBMS Lock ».
Ci-dessous, pour résolution, voici l’ensemble des propriétés à ajouter sur le « business service OSB » concerné par le conflit (le « business service » pointé dans les logs) via différentes interfaces d’édition. La valeur du « timeout » (600) est a été définie arbitrairement.
Vue texte (xml) :

  <jca:dynamic-endpoint-properties>
    <jca:endpoint-property>
      <jca:name>useOracleDBMSLockThrottle</jca:name>
      <jca:value>true</jca:value>
    </jca:endpoint-property>
    <jca:endpoint-property>
      <jca:name>useOracleDBMSLock</jca:name>
      <jca:value>true</jca:value>
    </jca:endpoint-property>
    <jca:endpoint-property>
      <jca:name>mutexTimeoutSecs</jca:name>
      <jca:value>600</jca:value>
    </jca:endpoint-property>
  </jca:dynamic-endpoint-properties>

 
Vue graphique (Eclipse) :
via Business Service Editor -> JCA Transport Configuration -> Dynamic EndPoint Properties

 
Vue Server Bus Console (sur l’édition de la ressource concernée) :