From: | Dave Cramer <pg(at)fastcrypt(dot)com> |
---|---|
To: | Stéphane RIFF <stephane(dot)riff(at)cerene(dot)fr> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: [SPAM] - Re: [SPAM] - Re: JDBC HighLoad - Found word(s) |
Date: | 2005-02-04 15:51:45 |
Message-ID: | 42039A11.5090801@fastcrypt.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Manuel Sugawara | 2005-02-04 18:07:47 | jar naming consitency |
Previous Message | Sebastiaan van Erk | 2005-02-04 15:42:34 | Re: [SPAM] - Re: [SPAM] - Re: JDBC HighLoad - Found word(s) |