(Continued from yesterday..)
So we dint know what was copying the instance attributes to other instances. If it was not the Batch Job, There is definitely a non thread safe code that's doing it. But with so many threads, how easy is it to track down the cause. A wild card search for static would result in a lot of static variables in code.
Thank fully, there was a small market tracking method. This method profiled all the requests. And the data collected was stored in DB. so we were able to look at the requests that were *possibly* causing this. From there it was only a matter of debugging the code.
Unfortunately, We didn't find anything statically referring in our code. but we soon realised it was happening in a (our own) library module that employed its own threading pattern. And there was a STATIC transactional variable. The rest of the story is imaginable. Remove the static reference rebuild the lib and deploy it.
But there are important lessons to be learnt here.
Of all the things, Stop declaring static for transactional variables. static - means static - IT should rarely change!! and by definition *common* in nature. If there is a user account object. It can never be static. even if you are using a HOLDER object, it should not be static. Get a clear picture on that.
And then, Stop using Threads in JEE unless you completely know what you are doing. The main reason threads were used here was that they were trying to implement pooling for connections to Mainframe. A better suggestion would be to employ Connection pools in the container. Stop using your own.
Finally, Keep options to profile your application. Once your application goes into production, you have a totally different picture than that of your Dev. Keeping a way to track the application solves a lot of headache and reduces speculation.
So we dint know what was copying the instance attributes to other instances. If it was not the Batch Job, There is definitely a non thread safe code that's doing it. But with so many threads, how easy is it to track down the cause. A wild card search for static would result in a lot of static variables in code.
Thank fully, there was a small market tracking method. This method profiled all the requests. And the data collected was stored in DB. so we were able to look at the requests that were *possibly* causing this. From there it was only a matter of debugging the code.
Unfortunately, We didn't find anything statically referring in our code. but we soon realised it was happening in a (our own) library module that employed its own threading pattern. And there was a STATIC transactional variable. The rest of the story is imaginable. Remove the static reference rebuild the lib and deploy it.
But there are important lessons to be learnt here.
Of all the things, Stop declaring static for transactional variables. static - means static - IT should rarely change!! and by definition *common* in nature. If there is a user account object. It can never be static. even if you are using a HOLDER object, it should not be static. Get a clear picture on that.
And then, Stop using Threads in JEE unless you completely know what you are doing. The main reason threads were used here was that they were trying to implement pooling for connections to Mainframe. A better suggestion would be to employ Connection pools in the container. Stop using your own.
Finally, Keep options to profile your application. Once your application goes into production, you have a totally different picture than that of your Dev. Keeping a way to track the application solves a lot of headache and reduces speculation.