Why are My Applications Timing Out?

ADAPTER Life-Cycle Management 2-51 Non-transactional adapters implement their own schemes to ensure delivery, without the use of transactional semantics. The Service Engine obtains a file from an inbound directory, processes the file, and sends the processed file to an output directory. The inbound adapter is limited to translation if there is one configured and publishing the translated content which is processed as a part of the business scenario. The business scenario can use the adapter to write to an output directory. However, during this process, if a failover occurs in as a response to a disaster, the file may be lost because of the nontransactional nature of the Oracle File Adapter. As a result, some files read by the inbound adapter might not be sent to the output directory. Of course, when you have a a single node cluster or no cluster, failover is not an option. The file adapter is not configured for high availability to avoid message loss, but rather to ensure consistent access to the file system and load balancing across cluster nodes. If you have a single node setup, then you do not need a high availability setup for the File adapter, and it will still not loose messages. Consequently, because it is non-transactional, you must configure the Oracle File Adapter for high availability, to ensure that files are not duplicated during a failover. The file adapter will never loose messages, but might duplicate some during disaster recovery. Additionally, if you have processing scenarios that include Transactional and Non-Transactional Adapters, you need to ensure file integrity within the context of the part of your processing that is Non-Transactional. The JMS adapter can also function with just local transactions, that is, a transaction that begins and commits independently from and within the boundary of a global JTA transaction, that is. the local transaction only spans the actual invocation of the adapter. 2.26.2.3 What Happened to My Application’s Rejected Messages? Can I do Anything With Them? Rejected messages are stored in the database specifically, in the rejected_message table by default. A default rejected message handler, which stores them on the file system, will participate if you have not defined any policy to handle the rejected messages explicitly. This handler stores the payload and properties of the message on the file system at a predefined location in WLS_HOME. Currently, the Oracle SOA suite does not provide the capability to resubmit rejected messages; consequently it is your responsibility to take care of the resubmission.