Thread: Problem with loginTimeout
Hi, I am new to this list, so hello everyone. I am having troubles with getConnection() and the loginTimeout property. I am working with a 7.4.2 server and I was also using the 7.4 jdbc driver (build 215). Everything is under Red Hat RHEL 3, JDK 1.4.2. My application is running under JBoss 3.2.6. With this version, there was no support for timeout when using getConnection(), so sometimes it takes 3 minutes for getConnection() to send an exception. I have to connect to 35 databases one after an other so the delay is really too important (3 * 35 minutes = 1h45). Looking at the mailing list archives, I saw posts concerning this problem and the solution of calling getConnection() in a separate Thread and dealing with the timeout (6 seconds) in the mail thread. I implemented this fix, but stumbled into an other problem: when a first getConnection() is still running, following getConnection() won't return a connection until the first one is finished. This implies that once a getConnection() timedout (the 6 seconds timeout), every other attempt to use getConnection() will also time out (6 seconds) until the first getConnection() will definitely fail (3 minutes). I don't see how I can find a solution for this problem, anyone can help me ? I tried updating to the latest JDBC driver (8.2 build 504), and the problem seems to be fixed. But then I am getting errors with my EJB Entities when trying to create new instances : Could not create entity org.postgresql.util.PSQLException: ERROR: column "tab_alarme_emis_pcc" is of type boolean but expression is of type character The corresponding field is defined as : - in the EJB entity: with @ejb.persistence column-name="TAB_ALARME_EMIS_PCC" public abstract Boolean getEmisPcc(); - in the database: with tab_alarme_emis_pcc boolean What is the problem ? Please help. Is there a global setting to have the pgdriver behaving as it was in 7.4 ? I spent almost the entire day on this problem and still haven't found a solution :( Thanks, Nicolas
Nicolas Vervelle wrote: > Hi, > > I am new to this list, so hello everyone. > > I am having troubles with getConnection() and the loginTimeout property. > > I am working with a 7.4.2 server and I was also using the 7.4 jdbc > driver (build 215). Everything is under Red Hat RHEL 3, JDK 1.4.2. > My application is running under JBoss 3.2.6. > > With this version, there was no support for timeout when using > getConnection(), so sometimes it takes 3 minutes for getConnection() to > send an exception. I have to connect to 35 databases one after an other > so the delay is really too important (3 * 35 minutes = 1h45). > Looking at the mailing list archives, I saw posts concerning this > problem and the solution of calling getConnection() in a separate Thread > and dealing with the timeout (6 seconds) in the mail thread. > I implemented this fix, but stumbled into an other problem: when a first > getConnection() is still running, following getConnection() won't return > a connection until the first one is finished. This implies that once a > getConnection() timedout (the 6 seconds timeout), every other attempt to > use getConnection() will also time out (6 seconds) until the first > getConnection() will definitely fail (3 minutes). > I don't see how I can find a solution for this problem, anyone can help > me ? > > I tried updating to the latest JDBC driver (8.2 build 504), and the > problem seems to be fixed. > But then I am getting errors with my EJB Entities when trying to create > new instances : > Could not create entity > org.postgresql.util.PSQLException: ERROR: column "tab_alarme_emis_pcc" > is of type boolean but expression is of type character > The corresponding field is defined as : > - in the EJB entity: with > @ejb.persistence column-name="TAB_ALARME_EMIS_PCC" > public abstract Boolean getEmisPcc(); > - in the database: with tab_alarme_emis_pcc boolean It seems there's a problem in your EJB container or mapping etc. causing it to send booleans as CHARs instead. > What is the problem ? Please help. > Is there a global setting to have the pgdriver behaving as it was in 7.4 ? Try protocolVersion=2, see http://jdbc.postgresql.org/documentation/82/connect.html#connection-parameters -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote: > Nicolas Vervelle wrote: >> I tried updating to the latest JDBC driver (8.2 build 504), and the >> problem seems to be fixed. >> But then I am getting errors with my EJB Entities when trying to >> create new instances : >> Could not create entity >> org.postgresql.util.PSQLException: ERROR: column >> "tab_alarme_emis_pcc" is of type boolean but expression is of type >> character >> The corresponding field is defined as : >> - in the EJB entity: with >> @ejb.persistence column-name="TAB_ALARME_EMIS_PCC" >> public abstract Boolean getEmisPcc(); >> - in the database: with tab_alarme_emis_pcc boolean > > It seems there's a problem in your EJB container or mapping etc. > causing it to send booleans as CHARs instead. > >> What is the problem ? Please help. >> Is there a global setting to have the pgdriver behaving as it was in >> 7.4 ? > > Try protocolVersion=2, see > http://jdbc.postgresql.org/documentation/82/connect.html#connection-parameters > > Thanks, protocolVersion=2 in the datasource configuration fixed the problem. Nicolas
On 12-Feb-07, at 11:46 AM, Heikki Linnakangas wrote: > Nicolas Vervelle wrote: >> Hi, >> I am new to this list, so hello everyone. >> I am having troubles with getConnection() and the loginTimeout >> property. >> I am working with a 7.4.2 server and I was also using the 7.4 jdbc >> driver (build 215). Everything is under Red Hat RHEL 3, JDK 1.4.2. >> My application is running under JBoss 3.2.6. >> With this version, there was no support for timeout when using >> getConnection(), so sometimes it takes 3 minutes for getConnection >> () to send an exception. I have to connect to 35 databases one >> after an other so the delay is really too important (3 * 35 >> minutes = 1h45). >> Looking at the mailing list archives, I saw posts concerning this >> problem and the solution of calling getConnection() in a separate >> Thread and dealing with the timeout (6 seconds) in the mail thread. >> I implemented this fix, but stumbled into an other problem: when a >> first getConnection() is still running, following getConnection() >> won't return a connection until the first one is finished. This >> implies that once a getConnection() timedout (the 6 seconds >> timeout), every other attempt to use getConnection() will also >> time out (6 seconds) until the first getConnection() will >> definitely fail (3 minutes). >> I don't see how I can find a solution for this problem, anyone can >> help me ? >> I tried updating to the latest JDBC driver (8.2 build 504), and >> the problem seems to be fixed. >> But then I am getting errors with my EJB Entities when trying to >> create new instances : >> Could not create entity >> org.postgresql.util.PSQLException: ERROR: column >> "tab_alarme_emis_pcc" is of type boolean but expression is of type >> character >> The corresponding field is defined as : >> - in the EJB entity: with >> @ejb.persistence column-name="TAB_ALARME_EMIS_PCC" >> public abstract Boolean getEmisPcc(); >> - in the database: with tab_alarme_emis_pcc boolean > > It seems there's a problem in your EJB container or mapping etc. > causing it to send booleans as CHARs instead. > >> What is the problem ? Please help. >> Is there a global setting to have the pgdriver behaving as it was >> in 7.4 ? > > Try protocolVersion=2, see http://jdbc.postgresql.org/documentation/ > 82/connect.html#connection-parameters > This is not a good solution. You are completely sidestepping all the advantages of prepared statements. The real solution is to fix the ejb persistence mechanism that thinks a boolean is a char. > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that > your > message can get through to the mailing list cleanly >