Problem with Database while using JNDI Lookup.

[dmjpro]

I thought that when the connection gets closed then all resources get closed .
I also included the ResultSet and Statement ;) . But if the Statement closed then only ResultSet closed. But now i got the point ..after closing Connection i am still able to access to iterate the ResultSet . Actually it is tested only with Postgres. Is it sun specified : ?

Now i tested another code ...

import org.apache.tomcat.dbcp.dbcp.cpdsadapter.DriverAdapterCPDS;
import org.apache.tomcat.dbcp.dbcp.datasources.SharedPoolDataSource;
 
        DriverAdapterCPDS l_adapter = new DriverAdapterCPDS();
        l_adapter.setDriver("org.postgresql.Driver");
        l_adapter.setUrl("jdbc:postgresql://10.29.32.68:5432/Admin");
        l_adapter.setUser("erp");
        l_adapter.setPassword("iiterp");
 
        SharedPoolDataSource l_ds = new SharedPoolDataSource();
        l_ds.setConnectionPoolDataSource(l_adapter);
        Connection l_con = l_ds.getConnection();
 
        Statement l_stmt = l_con.createStatement();
        ResultSet l_rs = l_stmt.executeQuery("select * from dpcode");
        l_con.close();
        while(l_rs.next()){System.out.println("Yahoo!!!");}
 

The Resultset is still getting iterated ...

But when I get the DataSource using the JNDI look up then my another code is not working ..Saying that the ResultSet is closed.
Could you help me to figure out ...

            Context l_ctx = new InitialContext();
            DataSource l_ds =                     (DataSource)l_ctx.lookup("java:/comp/env/jdbc/admindatasource");
            Connection l_con = l_ds.getConnection();
 
            Statement l_stmt = l_con.createStatement();
            ResultSet l_rs = l_stmt.executeQuery("select * from dpcode");
            l_con.close();
            while(l_rs.next()){System.out.println("Yahoo!!!");}
 

Please help me to figure out .. ;)

[JosAH]

A Connection is the owner of a Statement. A Statement is the owner of a ResultSet. When you close an object earlier in the chain the other objects, later in the chain, are also closed. A PooledConnection isn't closed when you get rid of it, i.e. it is simply returned to its pool. Read the API documentation for the close() method of a Connection: "If the close method is called and there is an active transaction, the results are implementation-defined. "

kind regards,

Jos

[dmjpro]

Then why does it happen to me ???
U mean that whats are happening that should not be ?
I could not get you ..yeah i know .when a connection(obtained from pool) closed then it simply goes to Pool and be reused later.
But these things are happening to me ?

[JosAH]

What part of "implementation-defined" was so difficult to understand? You're closing an object earlier in the chain: a Connection; nothing can be said about a Statement or ResultSet. The Connection could just be dumped in a pool again or it may be really closed.

kind regards,

Jos

[dmjpro]

Yeah all these things are implementation dependent ... But still there should be a standard logic to implement ....

[r035198x]

@dmjpro
Yes there is. Close the rs first, then the statement and then the connection.

[dmjpro]

Then why does it behave like a hell ???
Yeah i know ... i should close those resources sequentially ... But the code already developed .. it requires a lot of hurdle ...
That's why i was asking .. if make a raw connection and even also using a DataSource it working fine .. but if i get the DataBase using JNDI look up then it's not working .. i was looking for this answer ?

[JosAH]

@dmjpro
Because the code assumed a particular implementation defined behaviour; that's an error; e.g. in C and C++ you have to stay far away from "undefined behaviour" and "implementation defined behaviour". Same here: there's an error in the code; fix it and don't ask why anymore.

kind regards,

Jos

[dmjpro]

Don't get me wrong .......... According to the answer of r0... i asked why does this ... anyway the designed was wrong ;)

[JosAH]

@dmjpro
Erm, yes, that's what I was trying to tell you all the time in replies #2, #4 and #8, but glad you understand it now.

kind regards,

Jos