1)
Yes, You need to close connections.
Ensure that connections are *always* closed (even in cases of failure)
eg:
------------------------------------------------------------------
Connection conFromDS = null;
Statement stmt = null;
try{
conFromDS = Datasource.getConnection();
stmt = conFromDS.createStatement();
stmt.executeQuery();
}
catch (SQLException sqe) {
//log, take appropriate action
} finally {
try {
if (stmt != null) {
stmt.close(); // ensure that statement is always
closed
}
} catch (SQLException sqe) {
}
try {
if (conFromDS != null) {
conFromDS.close(); //ensure that connection is
always closed
}
} catch (SQLException sqe) {
}
}
------------------------------------------------------------------
2) w.r.t "maximum amount of cursors in database", you need to ensure
that statements, resultsets are always closed.
Thanks,
-Jagadish
On Tue, 2007-07-17 at 16:39 -0700, Marina Vatkina wrote:
> AFAIK you need to close all connections in GF (other than actual underline
> database connections if you ever need to get a hold of those).
>
> Regards,
> -marina
>
> Witold Szczerba wrote:
> > Hi there,
> > I have question about using JDBC DataSource in JavaEE application
> > using Glassfish.
> > This is how session bean can use DataSource:
> >
> > @Stateless
> > public class LoanCacheServiceBean implements LoanCacheServiceLocal {
> >
> > @Resource(name = "jdbc/sop")
> > private DataSource dataSource;
> >
> > public void someMethod() {
> > try {
> > dataSource.getConnection().createStatement().execute(someSQL);
> > } catch (SQLException ex) {
> > //log that exception
> > }
> > }
> > }
> >
> > In the example above, there is java.sql.Connection object established
> > from DataSource, then that connection is used to create and execute
> > some query.
> >
> > The question is: is the code above correct? I mean, do I need to close
> > that connection manually, or maybe, when transaction commits,
> > Glassfish will take that connection back into connection-pool?
> >
> > I am asking, because we had problems with our application recently. We
> > never had that issues when we were testing it in our office, but after
> > deploying that application on our customer's server, we had strange
> > exceptions after few days. First issue was about connection pool -
> > server was complaining it cannot use connection, because there was no
> > free connection left in pool (I was surprised, because I was thinking
> > that 32 connections was much more that our application will ever
> > need). I changed max-pool-size from 32 to 64 and everything was OK.
> > Today we had something even more strange: I found exceptions telling
> > that the maximum amount of cursors in database (300 by default) was
> > reached and we had to restart database and Glassfish :/
> >
> > Our application is using JPA almost everywhere, but few operations we
> > are doing using JDBC. I found, we never close connection in JDBC code
> > like in the example above.
> >
> > This is why I wrote that letter. I hope the problem with our
> > application is because we are not closing JDBC connection, but before
> > we correct that SessionBean I would like to know is this the cause of
> > our problem. If Glassfish returns that connection to pool after JTA
> > commits, then I have to seek for problem somewhere else :/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> > For additional commands, e-mail: users-help_at_glassfish.dev.java.net
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>