our JBoss (7.1.1) had some very strange issues after a hot-deployment.
We use a hibernate interceptor for setting the right database-schema for every query. We use this to separate customer data (every customer has its own schema).
When a customer makes a request against the server, the customer-name (also the schema name) is saved in the SecurityContextAssociation:
The hibernate-interceptor uses the SecurityContextAssociation to get the customers schema-name and to replace the placeholder-schama (configured in the persistence.xml) for every query. We also have some native queries where we build the sql-queries by our own (without the interceptor), but we also use the SecurityContextAssociation to determine the database-schema. This mechanism worked for a long time. In the past we've alos used the same mechanism with a JBoss 4.2.3. We have never had any problems with it.
Now we had a small update on our application. And we've decided to do a hot-deployment on the productive server. So, we've just replaced the old ear-file with the new one in the jboss deployments folder. After the ear has been "successfully" deployed, all this schema replacement stuff were messed up. One user has written the other in its schema. The strange thing is, that the queries were partially correct. So, in one ejb-transaction with multiple jpa-queries, some of the queries had the right schema set by the interceptor, but some had a completly wrong schema. The wrong schemas came from customers which were also working on the server at the same time. The same happend with the "self-build" native queries, where we have used the SecurityContextAssociation to get the schema to use. I suppose that somehow the ejb-context were messed up.
We have then restarted JBoss and now it seems that everything is alright again.
Though I'm wondering why and how could this happen? What could went wrong with the deployment to make the ejb-context completly inconsistent? Has anyone had similar problems, or is this possibly a known issue?