Re: [SPAM] - Re: [SPAM] - Re: JDBC HighLoad - Found word(s) - Mailing list pgsql-jdbc
From | Dave Cramer |
---|---|
Subject | Re: [SPAM] - Re: [SPAM] - Re: JDBC HighLoad - Found word(s) |
Date | |
Msg-id | 42039A11.5090801@fastcrypt.com Whole thread Raw |
In response to | Re: [SPAM] - Re: [SPAM] - Re: JDBC HighLoad - Found word(s) (Stéphane RIFF <stephane.riff@cerene.fr>) |
List | pgsql-jdbc |
Stephane, I didn't write the spec, I'm just explaining how to use it. Dave Stéphane RIFF wrote: > But with this usage i cannot reuse a preparedStatement. > Is it possible to create the preparedStatement in the constructor and > reused them > for each update. So that each thread has his own preparedStatements > because > each thread do an update every second, i also think that > preparedStatements > was good to use in this configuration but in your usage i have to > prepare the statement each time i get the connection. > > Dave Cramer wrote: > >> Stephane, >> >> No. >> >> Here is the basic usage of the connection ( regardless of the >> existance of the pool) >> >> get the connection >> prepare the statement >> execute the statement >> do something with result >> close statement >> close connection ( this allows the connection to be re-used by >> another request ) >> >> >> Having a pool does not change this pattern. >> >> All the pool does is cache connections so that they can be re-used by >> multiple threads without going through the overhead of opening the >> connection. >> It also minimizes the number of connections required for an >> application. For example if you have 1000 requests you might only >> need 100 connections since they will share >> the connections in the pool. >> >> Dave >> >> Stéphane RIFF wrote: >> >>> I thought that preparedStatement know what connection to use even if >>> i return it to the pool >>> >>> Dave Cramer wrote: >>> >>>> Stephane, >>>> >>>> Yes, that is true, but where do you get the connection from on the >>>> next iteration of the loop ? The constructor of SQLoader.... so the >>>> next loop it is gone. >>>> >>>> Dave >>>> >>>> Stéphane RIFF wrote: >>>> >>>>> I thought that the m_conn.close() released the connection to the >>>>> pool doesn't it ? >>>>> If i close the connection at the end of the loop byt a >>>>> SQLoader.close() this will >>>>> make one connection for each thread. I want each thread ask a >>>>> connection to the pool >>>>> and released it after each update. >>>>> >>>>> Thanks for your time >>>>> Bye >>>>> >>>>> Kris Jurka wrote: >>>>> >>>>>> On Fri, 4 Feb 2005, [ISO-8859-1] St�phane RIFF wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Hello, >>>>>>> I implement like you said in the last post but now i get some >>>>>>> errors like this : >>>>>>> >>>>>>> 2005-02-04 09:03:26,234 : [WARN] SQLoader - >>>>>>> java.sql.SQLException: >>>>>>> org.apache.commons.dbcp.DelegatingPreparedStatement is closed. >>>>>>> I attach the two class i you want to see >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Your main loop is written: >>>>>> >>>>>> SQLoader sl = new SQLoader(); >>>>>> for(int i=0;i<100;i++) { >>>>>> sl.saveTrame( ... ); >>>>>> } >>>>>> >>>>>> but the end of the saveTrame method you have: >>>>>> >>>>>> finally { >>>>>> try { >>>>>> m_conn.commit(); >>>>>> m_conn.close(); >>>>>> >>>>>> This closes the connection on the first iteration of the loop. >>>>>> I'd suggest something like adding SQLoader.close() which gets >>>>>> called at the end of the for loop. >>>>>> >>>>>> Kris Jurka >>>>>> >>>>>> ---------------------------(end of >>>>>> broadcast)--------------------------- >>>>>> TIP 8: explain analyze is your friend >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > -- Dave Cramer http://www.postgresintl.com 519 939 0336 ICQ#14675561
pgsql-jdbc by date: