cloudtechnician
asked on
Java Application is Unable to connect to correct schema(Error : 404)
While trying to start the tomcats we're getting 404 error message in application logs. When looking at the application logs it shows that application is trying to connect to some other schema instead looking/connecting to it's defined schema. Also, we're unable to start any tomcat now.
Below are the application logs :
Caused by: org.springframework.beans.
Could someone please suggest why is it happening. Actual schema name is not (COMPLIANCE), Actual schema is ABC_UAT, unable to understand why the hell is it looking for a column in a table which is in another schema.
PS : we're using Oracle.
Below are the application logs :
Caused by: org.springframework.beans.
Could someone please suggest why is it happening. Actual schema name is not (COMPLIANCE), Actual schema is ABC_UAT, unable to understand why the hell is it looking for a column in a table which is in another schema.
PS : we're using Oracle.
ASKER
We just restarted the tomcats on both the instances where application is deployed, after that this problem started.
There is no hardcoding of schema inside the code, it's just described in configuration file.
It was working pretty well before restarting the tomcats.
There is no hardcoding of schema inside the code, it's just described in configuration file.
It was working pretty well before restarting the tomcats.
>> it's just described in configuration file.
Maybe the config file changed since everything was last restarted.
Maybe the config file changed since everything was last restarted.
ASKER
If we restore WEBAPPS folder with old backup will it make any changes at the database, will the scripts execute again?
>> will the scripts execute again?
I don't know. I only know Oracle. If the config files changed then I probably wouldn't just try to replace them. They likely changed for a reason.
I don't know. I only know Oracle. If the config files changed then I probably wouldn't just try to replace them. They likely changed for a reason.
ASKER
Yes, we've confirmed that it looks Oracle issue, We locked the application account and restarted the tomcats to verify if application is trying to make connection to same schema and noticed in the logs it found out that the account is locked, which means it's trying to connect to the same schema but the question arises is why is it trying to make connection from other schema and reporting missing table in another schema. No where in application it's mention to connect to another schema. What is causing it to look for another schema.
>>but the question arises is why is it trying to make connection from other schema and reporting missing table in another schema
I cannot say. Oracle doesn't just randomly pick tables to access. Something somewhere is telling the app to look for that table in that schema. Maybe the app uses a view that uses that table?
Did someone log into the database and remove the column form the table in the compliance schema?
I would log into the database and describe the table COMPLIANCE.ANALYSIS_WORD_L
I cannot say. Oracle doesn't just randomly pick tables to access. Something somewhere is telling the app to look for that table in that schema. Maybe the app uses a view that uses that table?
Did someone log into the database and remove the column form the table in the compliance schema?
I would log into the database and describe the table COMPLIANCE.ANALYSIS_WORD_L
ASKER
We don't hard code any schema references in our code. I have also verified the entire codebase and did not find any places where we switch schemas. We inject JDBC datasource from Tomcat JNDI context. Connection parameters are configured in server.xml file in Tomcat’s conf directory.
I'm still confuse why is the wrong schema being called.
I'm still confuse why is the wrong schema being called.
If it isn't in your app code, then it either has to be in tomcat itself or in the database.
You might check the DBA_DEPENDENCIES view to see what might be dependent on COMPLIANCE.ANALYSIS_WORD_L
http://docs.oracle.com/cd/E11882_01/server.112/e40402/statviews_3148.htm#REFRN23053
You might check the DBA_DEPENDENCIES view to see what might be dependent on COMPLIANCE.ANALYSIS_WORD_L
http://docs.oracle.com/cd/E11882_01/server.112/e40402/statviews_3148.htm#REFRN23053
ASKER
Finally, we spun up an instance from the old DB AMI and pointed the application to the new DB. Application started working after pointing it to new DB. Looks like it was some sort of permission issue.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Did this ever work? If so, what changed?