I have an XML configuration file for my web application, which is read using JAXB, only once per JVM lifecycle - on the first call to the application. The results are cached in Java beans inside a singleton class - again, only once. This singleton class has a public method to read the data from the beans and output a list of item IDs for a specified category. This method is called once per request to the application.
<category code='AA'>
<item id='1' />
<item id='2' />
<item id='5' />
<item id='7' />
<item id='8' />
<item id='19' />
</category>
<category code='BB'>
<item id='12' />
<item id='13' />
<item id='15' />
<item id='17' />
<item id='18' />
<item id='19' />
</category>
The item IDs mentioned earlier are unique for a given category. The logic reading the beans and returning the list of IDs, when tested in development environment, holds up very well and returns the data as expected. However, in a production environment, the logic starts returning repeated IDs in the list after a couple of days, whenever a critical concurrency is reached.
I am absolutely positive that there is no other code in the application that calls any of the "set" mutators on the Java beans other than when the object is being initialized. The logs also indicate that the XML being read and beans being created is done only once per JVM lifecycle. Even so, when traffic to the application is high ( > 10 transactions per second or so), the output from these beans is being corrupted. Once corrupted, it stays that way until the JVM is recycled again.
One solution I have tried is to not share the beans between threads, and create them from the XML every time the application is invoked. This has fixed the repeated IDs problem, but I am concerned that JAXB operations in every application call may be a performance risk.
Any ideas why this is happening, and how we can avoid this problem when the beans are shared?
