Are the plain java client libraries thread-safe?
This is a copy of this thread "Is the pure java client thread-safe?"
Could you please anwer the question. The answer is very important for the design of our tool that we are developing against the RTC Plain Java API.
Content of referenced thread:
Is the pure java client thread-safe?For instance, if I do the following, is it safe and supported?public static void main(String[] args) {TeamPlatform.startup();login(monitor);//spawn multiple threads now, which get hold of the repository service TeamPlatform.getTeamRepositoryService().getTeamRepository(...)// and do various operations such as updating work items, creating new ones, downloading attachments etc//the main thread waits until the spawned threads die, and then does a TeamPlatform.shutdown();}Regards,Pradyumna
One answer
As far as I can answer this question:
I have used threads to perform concurrent activity using the API, in a similar fashion as described above, and it has worked for me in the past. The RTC Eclipse client also uses multiple threads. You can run operations in the background and not all operations run in the UI thread.
Ultimately the API accesses the Server at which level any of the operations is thread safe to an extent that concurrent operations would not break the data. All is done in transactions. That does not necessarily mean that the API does all the work for you.
Read operations are not a problem as far as I can tell, provided you make sure your data is isolated across threads e.g. you don't read into memory that is shared across threads.
If you update on the same items in parallel, you could get into situations that a thread wants to update data that is already changed. In this case you get a stale data exception. In this case you would have to resolve the data again and do the changes again.
My 2 cents.
I have used threads to perform concurrent activity using the API, in a similar fashion as described above, and it has worked for me in the past. The RTC Eclipse client also uses multiple threads. You can run operations in the background and not all operations run in the UI thread.
Ultimately the API accesses the Server at which level any of the operations is thread safe to an extent that concurrent operations would not break the data. All is done in transactions. That does not necessarily mean that the API does all the work for you.
Read operations are not a problem as far as I can tell, provided you make sure your data is isolated across threads e.g. you don't read into memory that is shared across threads.
If you update on the same items in parallel, you could get into situations that a thread wants to update data that is already changed. In this case you get a stale data exception. In this case you would have to resolve the data again and do the changes again.
My 2 cents.
Comments
Ok, thank you for your two cents! :)
That means it seems to work for some use cases (since you already did it) but there is not official document resp. statement from IBM development regarding this, right?
Marko
I have not seen an official statement. All the official information is in the API Doc JavaDoc.