I am using Hibernate with c3p0 for connection pooling. Since I am working in a multisharded database environment and the possibility of shards' downtime is a realistic use case scenario (by means external to the application at hand, e.g. someone just taking the shard down for whatever reason), I am trying to have c3p0 explicitly close the Hibernate session once it detects that the database connection is down so that I can skip the particular shard's session in my multi-shard scan.
Is there a way to configure c3p0 to notify Hibernate, by invoking Session.close() once it finds out that the connection is down so that calling Session.isOpen() can return a meaningful boolean?
RELATED: Preemptively and gracefully check that org.hibernate.Session is still connected (via c3p0)
the short answer is no, c3p0 won't help you here.
it sounds like (looking here and at your previous question) you are doing something that works at cross-purposes to c3p0, that is you are holding long-lived Sessions rather than creating Sessions on an as-needed basis and then destroying them promptly. that kind of thing is very fragile. it is the architecture Connection pools exist to avoid.
your best choice, IMO, would be "don't do that". don't ever cache Sessions at all. then ordinary Connection testing (perhaps with checkoutTimeout set too) will resolve the problem. if a shard is down, attempts to acquire a Connection will fail, and you can skip the shard if that's the best workaround.
c3p0 knows nothing whatsoever about hibernate. c3p0's author is grateful to hibernate for popularizing his (my) library, but c3p0 has no idea what a Session is, just a Connection. the only way that c3p0 could help you a little bit, in theory, would be that it could report to you an event when it notices that a database is down (which might be quite promptly or quite slowly depending on your configuration). you could respond to the event by close()ing sessions.
unfortunately, c3p0 doesn't (yet) offer hooks through which users could respond to acquisition failures. it might — that's a feature i'm thinking about adding for 0.9.6. but it doesn't now. however, it would be pretty trivial to implement something that polls your shards and closes their Sessions yourself. all c3p0 would do to notice outages would be to call DriverManager.getConnection( ... ) or dataSource.getConnection()and observe Exceptions. you can do that yourself!
i still strongly recommend the first solution, though. get rid of the long-lived Session objects.
Related
Having the following problem of understanding why a connection session exists that goes on for 6 hours and also holding a lock and breaking the thread the question is rased if a connection of XADataSource (Oracle driver) needs a Java reference at all to be kept alive.
In terms of distributed transaction set to kept till it is explicitly ended (keep-xa-conn-till-tx-complete=true) I wonder how a driver could decide wether to close connection and commit a transaction once the GC recycled the connection. Is there even a way for the DBMS to do so?
So the question goes how does a DBMS decide wether to abandon a distributed transaction or not.
The DBMS does not decide to end the transaction, the transaction manager does.
The transaction manager is set up to run in your application containers, whether they are Spring, J2EE application servers, or something else. They have to "know" they are distributed transaction managers by being configured correctly. In a distributed transaction environment, where you have multiple transactional applications and/or services interacting to complete a transaction, they must all be able to support distributed transactions to make proper use of the XADataSources and send the right signals up and down the chain for commit vs rollback.
Presuming that you have the above situation, multiple applications and/or services participating in a distributed transaction, it sounds as if one of them is not configured correctly. Something in the chain is not truly a distributed transaction, so that when it completes it's only completing locally and not sending the signal back down the line. So the distributed transaction never completes, holding the connection open.
Check the configuration of every application and/or service participating in the transaction. Add logging output on each that details whether the transaction is a distributed one or not. If you can't do that, then dd logging output to each that records the start and end of the transaction. Find the latest point in the sequence of actions where you see an open-transaction but not a close-transaction. If you see that, it's likely the node right after it in the chain that is doing something wrong.
Good luck.
I am reading about Connections vs DataSources in Java and I have some questions. Is a DataSource really just a manager and an abstraction of a Connection (or multiple connections)?
From docs:
A factory for connections to the physical data source that this DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the preferred means of getting a connection.
Actually, a DataSource is a provider of Connections and it has a variety of implementations which operate in different manners. Such as:
Basic implementation -- produces a standard Connection object
Connection pooling implementation -- produces a Connection object that will automatically participate in connection pooling. This
implementation works with a middle-tier connection pooling manager.
Distributed transaction implementation -- produces a Connection object that may be used for distributed transactions and almost always
participates in connection pooling. This implementation works with a
middle-tier transaction manager and almost always with a connection
pooling manager.
Connection is the connection :) DataSource is a manager of connections (pool of connections).
Data source is the source of your data, the connection is the driver.
DataSource is ill concept in its existing form as if it was meant to abstract interactions it should not return some SQL connection to interact with in the first place. Also it is overkill and XA is fantasy concept that some paid dearly for lack of reliable implementation in the world (I mean all enterprise commercial implementers simply fail and expose business... someone got hurt because of it in finance, but I will not mention names). In general, regardless if Sun or Oracle recommends it, it results in over-engineering and some technical dirt in code (dealing with contexts, extra steps to get to data, some external configurations... and in the end it is still specific to vendor implementations anyway). Some developed coroporate solutions that deal with pooling, connection recovery e.t.c much better based on plain connections and DriverManager than DataSource implemtations provided by enterprise DBMS vendors.
For the record I worked with both and I base it on facts encountered in different places. And if you doubt it then ask why you can see plain JDBC URL in Hibernate configuration all over the place in businesses. Many simply dump the heavyweigtt idea of J2EE and go lightweight... also using plain connections based on DriverManager.
You want to get your career on line then go ahead with XA DataSources and recovery of failed transactions where poor XA implemetation failed badly.
The DB driver I am working with (for a sybase DB) does not implement a Connection.isValid(). What is the most efficient way I can validate a db connection using a query (or otherwise) in Java?
Libraries such as C3P0 and DBCP allow you to provide a validation query which is typically something very simple such as "select 1". Hence, you could take the same approach or simply use either of these libraries (my recommendation would be C3P0).
However, rather than testing the connection prior to executing your query you could simply attempt to execute and then retry the operation if it fails because the connection is invalid. Alternatively you could consider a non-pooled connection approach where the connection is created on-the-fly each time (e.g. such as Spring's DriverManagerDataSource).
I mostly agree with Adamski's comment about using "select 1 from table" as an efficient way of checking connectivity and using connection pooling (e.g. commons-dbcp, C3PO).
Application servers (e.g. Websphere) allow you to configure this validation for you so your applciation code doesn't have to know about it. You have the choice of always having the connection checked prior to using it, or the connection pool being validated when a new connections is created. You can also purge connections periodically in case they get stale.
If you're not running in an application server you can use Common DBCP with the properties described here:
http://commons.apache.org/dbcp/configuration.html
Or C3PO and take a look at using the idleConnectionTestPeriod property. This link talks about use with Hibernate but its still relevant for C3PO generally
http://community.jboss.org/wiki/HowToConfigureTheC3P0ConnectionPool
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.
I'm using an object/relational mapper to talk to the database. The library in my case is iBatis which is also used for transaction management.
However, I recently had a case where iBatis didn't actually start a transaction even though startTransaction() etc. was called as documented.
After some debugging I found out that there was a configuration mistake on my side.
One might blame iBatis but I would like to avoid such misconceptions in the future.
So here's the question:
How can I programmatically assert that the current database connection is running in a transaction?
The databases I'm using are Oracle, MySQL and H2 (for testing).
I'm not 100% sure if this is absolutely indicative of being in a tx, but Connection.getAutoCommit() tells you if the connection is in auto-commit mode, where auto-commit "on" means "no transaction".
There may well be cases where this assertion does not hold, but most JDBC-based frameworks will use that setting to control transactions.