We have a third party jar used in our code. There is a class file in the jar which contains a STATIC variable defined in it.
Now, there is one application which is using this jar and modifying the value of this STATIC variable in multithreaded environment. We don't have access to modify the code of this jar.
Also, we are accessing the same jar file and value of that STATIC variable to implement some logic. Now, what is happening is that since our application and other application is running in parallel in multithreaded environment, so, while we are in between our code execution of some logic (say a block of 5 statments) which depend upon the value of that static variable, the processor executes the other application code in between and modifies the value of that variable and hence, breaking our code.
To elaborate the problem more clearly, let me put it this way ...
We have 2 parallel threads running that connect to MQ server.
There are get and send methods which use the properties like this..
Every time, I try to get the message from MQ, I do set these properties before calling my get/send method.
But, there are chances, that by the time my control reaches the get method, the processor has been preemptied and assigned to the other thread which might again change the properties, and when my control again reaches my first thread get method, it'll try to get message from the changed properties.
I hope, I am able to make my point clear.
Please let me know, if I am not clear.
Is it possible to excute the bunch of these 4 statements as a transaction, I mean if a thread starts executing it should not be preemptied by other thread until it executes all the 4 statements in the block.?
Yogesh, are you elaborating on somebody else's problem?
The resolution of your problem is quite easy: put the five lines into an synchronized block, and use a single object to synchronize on. I would be tempted to synchronize on MQEnvironment.class, since (presumably) it owns the static variables which are causing you problems.
Just a note though, to what Martin mentioned - If any other part of your code or the third party application's code doesn't use the same object to synchronize on or doesn't use synchronization at all for accessing those properties, then it's back to square one. Looking at that code, it's a bit weird why those properties are all static and instead couldn't have been designed to pass along a specific instance of MQEnvironment to whatever operations are using it.
Edit: Actually, I just saw that Martin has already made the point about the library not being a good one.