I have an application that is using Hibernate and PostgreSQL, I compile it with Maven to a WAR and deploy it to a Tomcat 8.0, and sometimes I have the problem of
this error :
"User lacks priviledge or object not found: TABLE_NAME".
Well obviously the answers found to this problem are always "Check the priviledges to that user, and check if the table/database exists".
This absolutely is not the problem because this happens sporadically, i.e. My application is working fine, and when I deploy a new version of it, sometimes after the deploy it throws out this error.
I always deploy my application with Jenkins, and the deploys to Tomcat are successful, the application is working, but if I invoke an action that consumes a database service, it goes haywire with this error. This clears up after 2 to 3 clean deploys on it (i.e. I stop Tomcat, clean the directory, start it and run deploy with Jenkins again with the same version of code).
Still it is very odd that after a clean deploy it does not solve the problem. Even after restarting the whole server (not Tomcat, the Windows Server), it still happens.
The closest explanation I read about possible causes to this, is that sometimes it can create a ghost connection to the database and when it tries to query something it can't because it is not really connected.
The database is on the same server as the Tomcat, so the application points to localhost to connect to the database. I don't think this is related because it also happens in a Quality Rnvironment where the database is in a different server.
My configuration file regarding database is this:
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<alias name="appDataSource" alias="jpaDataSource" />
<alias name="jpaTransactionManager" alias="appTransactionManager" />
<bean id="appDataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
<property name="driverClassName" value="org.postgresql.Driver" />
<property name="url" value="${postgre.url}" />
<!-- jdbc:postgresql://127.0.0.1:5432/DEV_DATABASE -->
<property name="username" value="${postgre.username}" />
<property name="password" value="${postgre.password}" />
</bean>
<bean id="entityManagerFactory"
class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="jpaDataSource" />
<property name="jpaVendorAdapter" ref="jpaVendorAdapter" />
<property name="packagesToScan" value="${persistence.jpa.packagesToScan}" />
<property name="jpaProperties">
<props>
<prop key="hibernate.temp.use_jdbc_metadata_defaults">false</prop>
<prop key="hibernate.jdbc.use_get_generated_keys">true</prop>
</props>
</property>
<property name="sharedCacheMode" value="ENABLE_SELECTIVE" />
<property name="validationMode" value="NONE" />
</bean>
</beans>
Anyone got ideias of what this could be?
It's been a few months and I've been able to find out what was happening.
Apparently I had a configuration of an embedded-database and sometimes (though rarely) the application would connect to this embedded-database and not the one that I had configured to connect to Postgres Database.
The tag was:
<jdbc:embedded-database id="appDataSource" />
Because this was an empty mockup database, it would fire up the error of "User lacks priviledge or object not found" because the table did not exist in this empty database.
After removing this, the problem was solved, it now always connects to the correct database.
Related
I'm trying to connect perform an integration test and for that I need the H2 db to recreate some views.
I am using these properties:
<bean id="internalXaDataSource" class="org.h2.jdbcx.JdbcDataSource">
<property name="URL" value="jdbc:h2:./target/testing/h2db/#{randomUUID1.toString()}/:testdb;MODE=MSSQLServer"/>
<property name="description" value="#{randomUUID1.toString()}jdbcXa"/>
<property name="user" value="sa"/>
<property name="password" value=""/>
</bean>
<bean id="h2Server" class="org.h2.tools.Server" factory-method="createTcpServer" init-method="start" destroy-method="stop">
<constructor-arg>
<array>
<value>-tcp</value>
<value>-tcpAllowOthers</value>
<value>-tcpPort</value>
<value>8043</value>
</array>
</constructor-arg>
</bean>
I've tried connecting in several different ways:
Using the debugger to get the generated URL
then connecting to it with a jdbc connection URL like:
jdbc:h2:./target/testing/h2db/#3434-sdfjsd9o3849-df34/:testdb;MODE=MSSQLServer
I have a successful connection but the DB is empty, no tables are shown. However, using the information schema to get the list of schemata in the database shows that the testdb database is there.
Via the tcp server
I've tried several different URLs, but none connect. e.g.
jdbc:h2:tcp://localhost:8043/testdb:public;LOCK_MODE=0
jdbc:h2:tcp://localhost:8043/:testdb;LOCK_MODE=0
This is worse - not able to connect - just hangs.
Changing the underlying datasource to run on a port
<bean id="internalXaDataSource" class="org.h2.jdbcx.JdbcDataSource" depends-on="h2Server">
<property name="URL" value="jdbc:h2:tcp://localhost:8043/mem:public;MODE=MSSQLServer"/>
<property name="description" value="#{randomUUID1.toString()}jdbcXa"/>
<property name="user" value="sa"/>
< property name="password" value=""/>
</bean>
This also just hangs when trying to connect.
Can you explain what am I doing wrong?
Thanks
Figured this out. Had paused the running integration test with the IntelliJ debugger so I could connect to H2. However the breakpoint setting was set to stop the entire JVM. Fixed by editing the breakdown setting in IntelliJ to only pause the thread. Then was able to connect via the third method above.
We have deployed a cluster to AWS configured to use Ignite as a hibernate 2nd level cache, and we're using S3 discovery. On startup we can see the nodes do connect to each other correctly.
However, when a hibernate entity is updated on one server, the change is not propagated through the cluster so other servers continue to have the old value.
Here is a snippet of our ignite config..
```
<!-- Basic configuration for transactional cache. -->
<bean id="transactional-cache" class="org.apache.ignite.configuration.CacheConfiguration" abstract="true">
<property name="cacheMode" value="REPLICATED"/>
<property name="atomicityMode" value="TRANSACTIONAL"/>
<property name="writeSynchronizationMode" value="FULL_ASYNC"/>
<property name="backups" value="0"/>
</bean>
<bean id="ignite.cfg" class="org.apache.ignite.configuration.IgniteConfiguration" >
<property name="discoverySpi" ref="discoverySpi"/>
<property name="gridName" value="hibernate-grid"/>
<property name="cacheConfiguration">
<list>
<bean parent="transactional-cache">
<property name="name" value="hibernate.io.milton.vfs.db.Auditable"/>
</bean>
```
The exact same application code, when configured with hazelcast 2nd level cache, does work.
I'm sure there's just something wrong with our config. Can anyone suggest a pointer?
Most likely you hit a known issue with binary format which is used as the default one in Ignite. See the warning callout here for details: https://apacheignite-mix.readme.io/docs/hibernate-l2-cache#l2-cache-configuration
Switching to OptimizedMarshaller should fix the issue.
I have an issue in my Spring MVC JDBC call. If I make the call quickly after starting the server, the JDBC connection is make in a second and the data is retrieved. Similarly, if the other DAOs are called in quick succession with one another, the connection is made soon. But if I try to call a DAO after a gap of even a few minutes, the JDBC connection takes forever to be done. It gets stuck on
"DataSourceUtils:110 - Fetching JDBC Connection from DataSource"
I have never had the patience to really check how long it takes to retrieve the connection but I've waited for 10 minutes and there was no sign of the connection being made.
Next, I try to restart the server at least. But JDBC obstructs even stopping of the server!! The console is stuck on this line:
"DisposableBeanAdapter:327 - Invoking destroy method 'close' on bean with name 'dataSource'"
Eventually I restart Eclipse and it works alright until there is a time gap again.
This is my bean definition for the data source:
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver" />
<property name="url" value="url" />
<property name="username" value="abc" />
<property name="password" value="abc" />
<property name="validationQuery" value="SELECT 1" />
<property name="testWhileIdle" value="true" />
<property name="maxActive" value="100" />
<property name="minIdle" value="10" />
<property name="initialSize" value="10" />
<property name="maxIdle" value="20" />
<property name="maxWait" value="1000" />
</bean>
<bean id="jdbcTemplate" class="org.springframework.jdbc.core.JdbcTemplate">
<property name="dataSource" ref="dataSource" />
</bean>
<bean id="getDataDao" class="com.project.dao.GetDataDao">
<constructor-arg index="0" ref="jdbcTemplate" />
<constructor-arg index="1" value="STORED_PROC_NAME"></constructor-arg>
</bean>
In my DAO file, I extend Spring's StoredProcedure class and this is the constructor:
public GetDataDao(JdbcTemplate jdbcTemplate, String spName) {
super(jdbcTemplate, spName);
declareParameter(new SqlParameter("p_input", Types.VARCHAR));
declareParameter(new SqlOutParameter("o_result", Types.VARCHAR));
compile();
}
In another function, this is how I call the SP:
spOutput = super.execute(spInput);
where spOutput and spInput are HashMaps.
Am I doing something wrong in my configuration? TIA.
I too had the exact same issue. I found that issue was consistent with a particular query, checked the query and found that issue was within query itself. Running query separately was also taking time. Query was converting a column to lower and that column was not indexed. Query was like lower(trim(column_name)), removed the lower and trim. It worked perfectly fine after that.
The additional code helps, but I do not see anything in it that would cause issue you are seeing. The most likely reason for issue you are seeing is that connections are being pulled out of the pool, but they are not being returned, and the pool eventually becomes starved. The dbcp pool is then later blocking your shutdown because these connections are still open, and probably hung.
To verify, you might try setting maxActive and similar settings to something much lower, perhaps even "1", and then verify that you get the same issue immediately.
Have you verified that your stored procedure is returning? i.e. You actually get spOutput for every call and the stored procedure itself is not hanging consistently or randomly?
If so, my only other suggestion is to post more code, especially from the call stack leading in to GetDataDao, and including whatever method in the DAO is making the sp.execute call. An assumption is that you are not using transactions, but if you are, then showing where you start/commit transaction in code would also be very important.
I've developed applications (running on Jboss server) with two different teams. One team had datasource configuration inside of the application WAR file and another one had it inside of the application server's standalone.xml. And I'm not sure which approach is better.
So, here are some advantages that I've found in defining datasource inside of the server's standalone.xml.
Defining datasource in server's standalone.xml is more secure than in war file. If the database connection credentials stored in the server's standalone.xml, which is almost never modified, it is safer than having the password inside of the war file, which is often transferred from developer's machines to the server and database configuration is spread by all developers computers.
By having datasource in standalone.xml, we can make war file smaller, as JDBC driver could be installed as a module and can be removed from war file. In addition, loading JDBC as module is more efficient as from classpath.
We can put datasource inside of the standalone.xml if we don't want the application development team be aware of database connection settings.
By having datasource configurations in application WAR file, I see the following advantages, which are:
Development team doesn't have permission to change Jboss configuration files in environment where Jboss is running. So DB connection only can be defined in application.
It is useful in development state, when developers often need to switch between different database connections. For example, the developer can specify connection when building a WAR file.
So I'd like to know if there are another advantages in both approaches. And on your opinion which approach is better?
In addition to the points noted in the question, another advantage in having the datasources outside the application is that it allows for using the same war file in different regions. This would allow the team to have different databases for different environments, like Test, Perf and Prod while using the same war file.
You can do a deployment once and then the war file which has been tested by your QA team can be promoted to the production region. This would make sure that no untested code goes into higher regions while avoiding the need for SCM forks and code freezes.
I favour having the datasource exposed by the application server with a caveat..
You need your development team to at least know their way around with your application server or to have at least access to the jboss console to review the configuration or change it..
Reason being that for example they need to monitor the connection usage of the datasource connection pool.. Since you're speaking about jboss, I don't know if the "live" bean for the datasource with jboss AS exposes the same information natively of for example oracle ucp (ucp .getStatistics is a godSend for more than one reason..).
Consider that EVEN if you internalize the datasource in xml, using the concept of profiles you can make some field of the xml being "filled" with some specific value in one or another property file based on the profile the application is loaded with..
e.g with spring you can surely do
<beans profile="local">
<bean id="dataSource" class="oracle.ucp.jdbc.PoolDataSourceFactory" factory-method="getPoolDataSource">
<property name="URL" value="jdbc:oracle:thin:#db00-ccea.labucs.int:1521:CCEA"/>
<property name="user" value="myuser_DCI"/>
<property name="password" value="mypassword_DCI"/>
<property name="connectionFactoryClassName" value="oracle.jdbc.pool.OracleConnectionPoolDataSource"/>
<property name="connectionPoolName" value="${name.connection.pool}"/>
<property name="minPoolSize" value="5"/>
<property name="maxPoolSize" value="1000"/>
<property name="maxIdleTime" value="3000"/>
<property name="maxStatements" value="3000"/>
<property name="validateConnectionOnBorrow" value="true" />
<property name="inactiveConnectionTimeout" value="3000" />
<property name="connectionWaitTimeout" value="3000"/>
<property name="abandonedConnectionTimeout" value="3000"/>
<qualifier value ="dataSourceDCI" />
</bean>
<orcl:pooling-datasource id="dataAltSource"
url="jdbc:oracle:thin:#db00-ccea.labucs.int:1521:CCEA" username="some_OWN" password="some_OWN"/>
<util:properties id="flyway.prop" location="classpath:config_local.properties"/>
</beans>
meaning on local profile load the properties from the config_loca.properties file inside the classpath
and have as well
<beans profile="qa">
<bean id="dataSource" class="oracle.ucp.jdbc.PoolDataSourceFactory" factory-method="getPoolDataSource">
<property name="URL" value="jdbc:oracle:thin:#db00-ccea.labucs.int:1521:CCEA"/>
<property name="user" value="myuserQA_DCI"/>
<property name="password" value="myuserQA_DCI"/>
<property name="connectionFactoryClassName" value="oracle.jdbc.pool.OracleConnectionPoolDataSource"/>
<property name="connectionPoolName" value="${name.connection.pool}"/>
<property name="minPoolSize" value="5"/>
<property name="maxPoolSize" value="1000"/>
<property name="maxIdleTime" value="3000"/>
<property name="maxStatements" value="3000"/>
<property name="validateConnectionOnBorrow" value="true" />
<property name="inactiveConnectionTimeout" value="3000" />
<property name="connectionWaitTimeout" value="3000"/>
<property name="abandonedConnectionTimeout" value="3000"/>
<qualifier value ="dataSourceDCI" />
</bean>
<bean id="dataAltSource" class="oracle.ucp.jdbc.PoolDataSourceFactory" factory-method="getPoolDataSource">
<property name="URL" value="jdbc:oracle:thin:#db00-ccea.labucs.int:1521:CCEA"/>
<property name="user" value="myuserQA_OWN"/>
<property name="password" value="myuserQA_OWN"/>
<property name="connectionFactoryClassName" value="oracle.jdbc.pool.OracleConnectionPoolDataSource"/>
<property name="connectionPoolName" value="${name.connection.pool}"/>
<property name="minPoolSize" value="5"/>
<property name="maxPoolSize" value="1000"/>
<property name="maxIdleTime" value="3000"/>
<property name="maxStatements" value="3000"/>
<property name="validateConnectionOnBorrow" value="true" />
<property name="inactiveConnectionTimeout" value="3000" />
<property name="connectionWaitTimeout" value="3000"/>
<property name="abandonedConnectionTimeout" value="3000"/>
</bean>
<util:properties id="flyway.prop" location="file:///${prefix.iam.dir}/${filecert.iam.path}/external.properties"/>
</beans>
thus in your QA environment or other non-dev environment you instead refer to the external xml file and not to the one integrated in the war..
You can even include username and password to be "filled" via the internal//external properties file to enhance the security if you're concerned.
In order to properly verify your application works, you should try in a staging server before sending it to production.
In that scenario, the war file you install into production, should be the same that you tested, so you shouldn't need to change anything for te application to work in a different environment with different database connections.
So, the database configuration shouldn't be in the war file but in the application server. Additionally, you make the system administrator's live easier because they don't need to manipulate (uncompress and change) your war to install it in a server.
In the very early development live of the application, it can be useful to add the database (and any other development configuration) to reduce the time a developer can put his/her hands on the project and starts programming without having to configure the application in a development application server.
For me, the number one benefit of having all data-source configuration out of the war file is ease of deployment.
If I read your question correctly, you can't ever deploy the exact same build to multiple environments if you include any configuration in the build. A direct implication is you can never deploy you DEV build to QA and more importantly, you can't deploy your QA build to PROD or UAT. This might cause headaches if your process is audited.
If I mis-understood your question, please let me know, otherwise, I hope this helps.
I am struggling with getting the localization to work when I deploy my app to tomcat.
I've got this setup in my applicationContext.xml:
<!-- Configures Handler Interceptors -->
<mvc:interceptors>
<!-- Changes the locale when a 'locale' request parameter is sent; e.g. /?locale=de -->
<bean class="org.springframework.web.servlet.i18n.LocaleChangeInterceptor" >
<property name="paramName" value="locale" />
</bean>
</mvc:interceptors>
<!-- Saves a locale change using a cookie -->
<bean id="localeResolver" class="org.springframework.web.servlet.i18n.CookieLocaleResolver">
<property name="defaultLocale" value="no" />
</bean>
<!-- Application Message Bundle -->
<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
<property name="useCodeAsDefaultMessage" value="true" />
<property name="basename" value="classpath:language" />
<property name="cacheSeconds" value="0" />
</bean>
Now, the localization works just fine when I run it from Jetty locally.
It's when I run the app from tomcat that it consequentially displays the language from the language_en.properties file, not my default file language.properties. And when I try to change the locale with ?locale=no (norwegian) nothing happends to the language on the site, but the log shows that the locale is actually changed to "no".
Has someone got any solutions or suggestion to solution to this, or maybe an alternative way of setting up the localization. I am open for anything and everything.
Try
classpath*:language
ie, search ALL classpaths. Depending on where you are deploying your resource bundles, they may end up in different places in the classloader hierarchy in tomcat and jetty.
FINALLY! I solved it!
I had to set the JvmOptions:
-Duser.language=no
-Duser.region=NO
in order for tomcat to use the language.properties and not the language_en.properties file.
And for some strange reason it now also works when setting the locale (?locale=en) to english too.