One of the restrictions when dealing with a short running process is that it must always run within a single transaction. The implication is that the process must complete within the default transaction timeout window. On an application server, this is 120s.
We had an issue where our Process Server was creating a large number of locks to rows on the SQL Server table. Eventually, SQL Server escalation would kick in and the entire table would lock. This would preclude other users of the database from being able to read/insert data.
Upon inspection of the offending process, we found that a short running process contained three nested loops which performed multiple invocations against the SQL server database. On the original test data, there weren’t enough nested objects created to determine if a large object could complete within 120s.
In addition, by default in WebSphere Application Server there are 10 activation specs that can process messages from a queue in parallel. This means that you need to ensure thete are enough database connections to service the requests.
Our solution to the problem was to break the transaction down into smaller parts and transmit the parts via JMS queues to new modules. A one-way invocation does not require the source bpel to block for a response, so it is able to now complete within the transaction timeout boundary.
