My application is trowing the following exception:
java.sql.SQLException: Connection is not associated with a managed connection.org.jboss.resource.adapter.jdbc.jdk6.WrappedConnectionJDK6#4fe91321
This is happening in production I'm not able to get this problem in development and for that I'm not able to solve it.
The root of the exception is code line dbConn.prepareStatement(sql);
From what I was able to find in the web, the cause for this can be:
Over jdbc connection, a jboss connection is wrapped but the wrapper is empty. The original jdbc connection inside is no longer there.
JDBC Connection is already closed and trying to work with close connection is the reason why I'm getting this exception.
The transaction manger detects transaction that is taking to long then the transaction timeout.
So if someone can point me what is the problem because I'm not able to get this problem in mine development environment.
Also what logs can I add that will help me detect the problem in production - I'm using Java, JBoss, Postgre.
I'have enable connection close monitoringa, and also to add is that the issue is not consistent
I just resolved the issue.
It's my jndi driver not compatible with the latest java frameworks.
I'm using Oracle db and ojdbc6, and i download a latest ojdbc6 from maven repository and replace the old same name jar file. It works like bird now.
If you are using an EJB, it's possible that your Stateless Session Bean Pool is not big enough. The connection can't find an associated thread.
Maybe you have an extended Transaction for a not Stateful Session Bean, wich is maybe not a good idea.
Related
I've a Spring Boot Java application in production that uses ActiveJDBC to access a MariaDB database.
If at launch the application boots before the db server, of if the db server crashes and restarts, the apps doesn't re-estabilish the connection with the db.
ActiveJDBC is on version 1.4.13 and if possible I'd prefer not upgrading it, to avoid possible breakages. The db parameters are configured using the database.properties file and typically the usage pattern is:
try {
Base.open();
...
} finally {
Base.close();
}
Is there a way to circumvent this problem, without monitoring and relaunching the application? Maybe using connection pools? If this is the case, are there any docs or examples?
If you are using a direct JDBC connection in your database.properties file, a new connection will be open every time you execute Base.open(). This means that any old connection that is broken is not relevant anymore. If you use a JDNI pool such as:
production.jndi=java:comp/env/jdbc/acme
then you want to configure your containers' pool to ensure that every connection served from the pool is valid just before the pool serves the connection to your app. It is up to the implementation and documentation of your container/pool how to do that.
In any case, I do not think you are going to have issues.
I am using Weblogic 12c and I am getting the below error while committing distributed transactions in my application.
"java.sql.SQLException: Cannot call Connection.commit in distributed transaction. Transaction Manager will commit the resource manager when the distributed transaction is committed"
The part of code throwing exception is:
Session sessionNew = HibernateService.getService().getSession();
sessionNew.connection().commit();
This question has been asked several times, but the solution I am seeking is different.
The most common solution is to disable XA transactions to resolve the issue.
But my application contains more than resources like database, JMS etc.
Can anyone please suggest a solution other than the one mentioned above.
Also, I needed to understand if there is any relation between JTA transaction timeout value and the above-mentioned error.
Thanks a lot.
Most likely if you switch #TransactionManagement (TransactionManagementType.CONTAINER) to #TransactionManagement (TransactionManagementType.BEAN) this error will no longer occur.
So you define what you define when you commit, not the server.
We've been working on an application that uses Tomcat 8 throught connection pool. We control Optimistic exceptions with #Version field, and we control transactions with Entitymanagers isolated by ThreadLocal.
However, the application triggers a concurrency exception sometimes with hangs other processes and requieres to restart the server.
The exception is always like this:
Caused by: Exception [EclipseLink-2004] (Eclipse Persistence Services - 2.6.4.v20160829-44060b6):
org.eclipse.persistence.exceptions.ConcurrencyException
Exception Description: A signal was attempted before wait() on ConcurrencyManager. This normally means that an attempt was made to commit or rollback a transaction before it was started, or to rollback a transaction twice.
at org.eclipse.persistence.exceptions.ConcurrencyException.signalAttemptedBeforeWait(ConcurrencyException.java:84)
at org.eclipse.persistence.internal.helper.ConcurrencyManager.releaseReadLock(ConcurrencyManager.java:468)
at org.eclipse.persistence.internal.identitymaps.CacheKey.releaseReadLock(CacheKey.java:475)
We've been trying to solve this problem or find any specific information about this error with no result. We even followed instructions in https://wiki.eclipse.org/EclipseLink/FAQ/JPA#How_to_diagnose_and_resolve_hangs_and_deadlocks.3F.
Disabling cache seems to solve the problem, but we cannt afford to not use cache due to performance needs.
Any help would be appreciated.
Thanks
Finally, after six months of headaches, I managed to solve the problem.
The general error was EclipseLink-2004. If you check Eclipselink error reference:
Eclipse link error reference page, it says "Verify transactions in the application".
I've been using a application managed Entity Managers. To control that transactions were single-thread I used this ManagerHelper class:
EntityManagerHelper
The problem was that I was putting a managed object inside a Session attribute. I don't really understand the process inside, but somehow it created new transactions outside the main transaction if it was used to query. Moving the object to Request attributes solved the problem.
I hope this helps to someone in the future.
Best regards
our project is deployed on the cloud but we need to shutdown and restart tomcat7 everyday otherwise "org.hibernate.exception.JDBCConnectionException: Cannot open connection" exception will rise, please help me to resolve this.
I'm guessing that you have a leak somewhere in your code which gets a connection without returning it to the pool (via Connection.close()).
Spring's JdbcTemplate exists mainly to prevent cases like this from ever occurring.
I'd look through the code for methods which get a connection but don't call Connection.close() in a finally block.
I recently wanted to prevent connection leaks but didn't want all of spring's dependencies so I wrote a very simple JdbcTemplate here. You might consider doing the same to avoid this from happening again (or use spring's version)
We have an application that needs to access a database that is owned by a different team.
That database has security inside the database (triggers, table permissions, etc) and so we need to establish a connection to the database using the same username/password that connected to our EJB.
We're running on JBoss 5.1. Standard Java EE solutions are preferred, but JBoss specific answers will do.
At the moment our solution is
Create a datasource in JBoss with no user-id password
Require the client to pass their username/password into the EJB (the EJB is a stateful session bean (SFSB), and remembers the username/password)
The session bean creates a new connection using DataSource.getConnection(String, String)
The connection is "created" from the datasource at the start of each request (The datasource implementation might reuse an existing connection)
The main problem we have is connection pooling.
The JBoss connection pool doesn't manage separate pools for each username - they're all thrown into 1 big pool, and the username is checked after the object is retrieved from the pool (inside InternalManagedConnectionPool).
If the usernames don't match, then the connection is removed from the pool & destroyed.
This means that as soon as we have 2 users, there's a 50% chance that any connection that is put into the pool will be destroyed when it is next accessed. And as we increase the number of users, those odds get a lot worse.
We can't simply create 1 connection in the SFSB and retain it because JBoss is too smart for us, and it detects that we've left a connection open and automatically returns it to the pool for us, so the next request to the SFSB will fail with a "not associated" connection.
It would also be nice if we could simply get JBoss to create a connection as "the currently logged in user", but the solution we have is bearable.
My googling has failed to find any recommended patterns for doing this sort of thing. Everyone seems to assume that you want your datasource to use a single user for all connections (which is nice when it's possible, but I can't do that in this case)
The only solutions I can some up with are
Don't use a container provided datasource. Put the JDBC URL into a configuration value somewhere and create connections myself (possibly with the help of spring)
Bind a different Datasource implementation (possibly a custom one) into JNDI
Has anyone got any better solutions? Or pointers to recommended practices in this area?
(The database is Sybase ASE 15, but I doubt that makes any difference to the solution)
A bit more reading of the documentation has led me to what appears to be the solution.
Adding
<application-managed-security/>
into my datasource file seems to have fixed the problem of pooling the connections.
I'm not sure how I missed that the first time around.