6

Is it possible to do the multi-threading in java application while talking to Salesforce using SOAP APIs? I tried it myself and it seemed to work fine. But according to http://boards.developerforce.com/t5/Java-Development/multithreaded-java-to-salesforce/td-p/142406, it also seem to suggest that it can work if each thread open its own connection which is not very clear to me.

AFAIK, even multiple JVMs on different hosts get same sessionId then how can each thread open it's own connection?

Also Salesforce SOAP API guide at http://www.salesforce.com/us/developer/docs/api/index.htm says

Do Not Design a Multi-Threaded Client Application. Multi-threading is not allowed for a single client application using the SOAP-based API.

I am little confused about all this, does anbydoy know why multi-threading should not be used?

5

Multi-threading offers at least a few distinct disadvantages in terms of the SOAP API. First, each QueryResultLocator can only be accessed by a single thread at once. This means that, while you could design multiple threads for retrieving and handling the data, only one thread at a time may actively be using a QueryResultLocator; other threads should get an error. Secondly, long-running queries use cursors, and each unique user is limited to the number of concurrent cursors they can hold open at once. Opening more than the limit results in the oldest queries being dropped (effectively terminating them). This means that multiple queries running side by side should be avoided when possible. Thirdly, as I understand it, the SOAP libraries of Java do not support threading directly, further complicating the issue. Fourthly, any application that's deemed to be using too many resources will simply be cut off (i.e. will not be allowed to run any API calls at all). While this may seem draconian, it's there to ensure that all clients using the platform have equal access to resources.

| improve this answer | |
  • You've touched on many important design decisions that can easily be overlooked, including the limited number of cursors available. – Mike Chale Jul 2 '13 at 14:25
  • Thanks. Seems there are lot of issues in it. Regarding limitation of concurrent cursors and QueryResultLocator, are they also applicable on just doing update calls via binding.update (SObject[] objects) call? – RandomQuestion Jul 2 '13 at 17:58
  • Update calls are not affected by cursors, and generally concurrent updates are possible, but one should not try to update the same record in multiple threads concurrently (a database lock will prevent this from happening), but nothing would stop a developer from sending multiple updates at once. – sfdcfox Jul 2 '13 at 20:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.