Re: [SPAM] - Re: [SPAM] - Re: JDBC HighLoad - Found word(s)

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

In response to

Browse pgsql-jdbc by date

  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)