2013/4/5 Jean-Claude Haw-King-Chon <jchaw-king-c...@medifirst.fr>:
> Le 05/04/2013 13:09, Konstantin Kolinko a écrit :
>>
>> 2013/4/5 Jean-Claude Haw-King-Chon <jchaw-king-c...@medifirst.fr>:
>>>
>>> Hi,
>>>
>>> I use the connection pool of tomcat7 and set a connection in a
>>> ThreadLocal.
>>> The context is a web application : the threadLocal is configured when the
>>> http request is initialized. The jdbc connection is closed and removed
>>> from
>>> the threadLocal when the resquest is destroyed.
>>>
>> 1. What exactly do you mean by "initialized" and "destroyed"?
>>
>>> If I'm not mistaken, each http request is treated by one thread by
>>> tomcat.
>>> So, I have one jdbc connection for each request ( = thread).
>>
>> 2. No. It depends on how you use it and at what points in time you look
>> at it.
>>
>> If you look at it in a call chain, e.g. using try{ } finally block in
>> a Filter, then yes, all calls inside of "try" belong to the same
>> thread.
>>
>> If you return processing to Tomcat and Tomcat makes a different call
>> into your code (e.g. using Async or Comet APIs), then that call can be
>> using a different thread from a thread pool.
>>
>>> (...)
>>>
>>> My problem appears when I use Ajax. For 2 successive ajax request, I have
>>> the error "Connection closed" : it's a random problem (the stacktrace is
>>> not
>>> the same for the 2 attemps and it's not depending of the thread execution
>>> order).
>>>
>>> I know this issue :
>>>
>>> http://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#Random_Connection_Closed_Exceptions
>>>
>>> "These can occur when one request gets a db connection from the
>>> connection
>>> pool and closes it twice. When using a connection pool, closing the
>>> connection just returns it to the pool for reuse by another request, it
>>> doesn't close the connection. And Tomcat uses multiple threads to handle
>>> concurrent requests"
>>>
>>> But, I'm sure, I always close the connection only once.
>>> I use too the "validationQuery" and "testOnBorrow" parameters.
>>>
>>> Is it possible that the connection pool returns the same connection for 2
>>> different threads?
>>>
>> You can check its hash code.
>>
>>> So I don't understand why my connection is closed during the treatment.
>>>
>> Best regards,
>> Konstantin Kolinko
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
> 1. What exactly do you mean by "initialized" and "destroyed"?
>
> Sorry, to be more precise, 2 approches has been tested :
>
> 1) The connection is initialized in the servlet by a method called by
> "doGet" or "doPost".
> But the connection is closed (and removed from the threadLocal) by a
> ServletRequestListener in the override of the "requestDestroyed" method.
>
> 2) The connection is initialized in the servlet by a method called by
> "doGet" or "doPost". The process is encapsuled in a try/catch/finally block.
> The connection is closed (and removed from the threadLocal) in the finally
> block.
>
> These 2 approches didn't work (random closed connection).
>
You should go with 2).
>
>
> 2. No. It depends on how you use it and at what points in time you look at
> it.
>
> So for the 2 approches, I'm in a call chain.
>
>
>
> Is it possible that the connection pool returns the same connection for 2
> different threads?
> You can check its hash code.
>
> Thank you for this tip. The thread name and the connection hashCode are now
> logged : I'm trying to understand the mechanism.
> The first results show that the problem appears with connections precedently
> closed...
>
> My configuration :
>
> <Resource
> name="jdbc/607"
> auth="Container"
> type="javax.sql.DataSource"
> username="xxxxx"
> password="xxxxx"
> driverClassName="com.mysql.jdbc.Driver"
> url="jdbc:mysql://localhost:3306/XXXXX"
> removeAbandoned="true"
> removeAbandonedTimeout="300"
> testOnBorrow="true"
> validationQuery="SELECT 1"
> logAbandoned="true"
> />
> Tomcat 7.0.29
> Linux Fedora Core 12
>
Do you have queries that run or are used for more than 5 minutes in a
single request?
If so, then your removeAbandonedTimeout is too short and
"removeAbandoned" will close them.
http://commons.apache.org/proper/commons-dbcp/configuration.html
BTW, your pool size is 8.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
