How to properly keep a DB connection from a Connec

问题:

I'm using JBoss AS 7.1 as a server and I have my DataSource configured with pooling. I'm quite new to this so please excuse any rookie mistakes... after all I'm here to learn.

When a client logs-in it gets a connection to the database and I need to keep that connection(from the pool) open until the user logs-out or the HttpSession expires. This is an absolute requirement coming from our DB Admin. who says that he needs the DB session variables. I am using a servlet for all this.

Playing with the possibilities I have encountered 2 major problems:

1. As far as I see JBoss automatically closes unused connections => my opened connection returns to the pool. So this might not be the right path.

2. If I try to store/recall the Connection object like this:

   private Hashtable<String, Connection> connections = new Hashtable<String, Connection>();
   
   try {
       String strDSName1 = "java:/OracleDSJNDI";
       ctx = new InitialContext();
       ds1 = (javax.sql.DataSource) ctx.lookup(strDSName1);
   
       System.out.println("Got 1'st ds.");
   
   } catch (Exception e) {
       System.out.println("ERROR getting 1'st DS : " + e);
   }
   
   connection = ds1.getConnection();
   connections.put(session.getId(), connection);
   
   conn = (Connection) connections.get(sessionID);
   

   it throws this exception:

   java.sql.SQLException: Connection is not associated with a managed connection.org.jboss.jca.adapters.jdbc.jdk6.WrappedConnectionJDK6@dee1f37

My question is: How do I properly keep my connection opened?

Thanks

回答1:

How do I properly keep my connection opened?

You must not do that, let the connection pool handle this.

---

Behind the scenes, the connection pool will keep a bunch of database connections to the database engine (MySQL, Oracle, SQL Server... depends how you configure it) in SLEEPING state. When you execute this code:

//avoiding all the particular exceptions just for code simplicity purposes...
//in real world applications, you must handle each of these exceptions
public Connection getConnection() throws Exception {
    ctx = new InitialContext();
    ds1 = (javax.sql.DataSource) ctx.lookup(strDSName1);
    return ds1.getConnection();
}

You're asking to the connection pool to retrieve one of these connections available. The connection pool will give you a database connection (if available) and let you use it as long as you want. Then you use it wherever you want/need and close it:

public void foo() throws Exception {
    Connection connection = getConnection();
    //do what you want/need...

    //in the end, you close the connection
    //this is A MUST!
    connection.close();
}

When executing connection.close() from a connection retrieved by the connection pool, you're not closing the physical database connection but notifying the connection pool this specific database connection must return to the SLEEPING state.

---

Some advices from the explanation:

• You must not try to keep the connection alive, that's connection pool's job.
• You must not try to store the connections in any cache-like structure, that's connection pool's job.
• You must retrieve a java.sql.Connection in the shortest scope you will need it. Once you have used it, close it.

回答2:

Your DBA is basically requiring you to avoid connection pooling by making the database connection equivalent to the user's session.

So one option is to not use the connection pool, and instead roll your own functionality that opens/closes the database connection around the user's session. That seems complicated and unusual though.

Another option is to examine the DBA's requirement. The DBA may have to adapt to the idea that he'll need to track state in a different way, e.g. by using a key related to the session to store the state he needs in a table, instead of storing state in the connection layer.

Generally speaking storing state in some component's session handling is adding indirect complexity, because you start having to care about how the component handles expiry and uniqueness, as you're finding here where the HTTP session state handles this differently from the database session.