On 30/06/2013 18:06, Noah White wrote:
> Sahoo,
>
> I think the only way to affect the behavior I would like is to put the NOT_SUPPORTED logic in an @Asynchronous method that the REQUIRES_NEW calls. However, the introduction of the async thread to the code path has its own ramifications with respect to the state of the system.
>
> I guess this comes down to the definition of a 'connection leak'. Is it simply a connection which has been open for a period of time longer then the leak timeout value regardless of the presence of traffic across it during that time and regardless of the state of the transaction context (suspended etc.)?
I believe its the former. It is a simple timer that is started when a
connection is returned to the application, which will trigger when the
leak timeout period has passed. From a support perspective we'd
normally only suggest enabling the leak timeout when the pool keeps
running out of free connections and the max wait time is exceeded. That
simply provides a report in the log file with the call stack of the
thread that obtained the connection to allow someone to try to figure
out if there is an error in the connection handling logic in the
application, which unfortunately is the most common cause of leaks.
Enabling the leak reclaim option to then destroy the connection is an
option to attempt to provide relief until the application code is
corrected, but I've seen it cause problems, especially when the leak
timeout has been set too low and the connection is being actively used,
and its locked by the driver.
> Or is it more nuanced? To me it would make sense for it to take into account the state of the context and pause the timer since the context is being explicitly driven/set by the application logic.
>
> -Noah
>
>
> On Jun 30, 2013, at 2:09 AM, Sahoo <sanjeeb.sahoo_at_oracle.com> wrote:
>
>> How can the connection which is still associated with a valid transaction be categorised as a leaked connection?I also expect the same behavior expected by Noah.
>>
>> Thanks,
>> Sahoo
>> On Saturday 29 June 2013 03:00 AM, Marina Vatkina wrote:
>>> I don't think the resource manager or transaction manager stop the clocks when transaction is suspended.
>>>
>>> -marina
>>>
>>> On 6/28/13 2:20 PM, Noah White wrote:
>>>> If an EJB method with a TX attribute of REQUIRES_NEW is invoked and it in turn invokes an EJB method with a TX attribute of NOT_SUPPORTED the container is supposed to suspend the association of the tx context with the current thread before invoking the NOT_SUPPORTED method.
>>>>
>>>> My question is if the NOT_SUPPORTED method takes longer then the JDBC Connection Pool's "Connection Leak Timeout" will it get tripped or does this timeout not apply while a TX context is suspended?
>>>>
>>>> I hope for the later but I suspect the former. Can anyone clarify. This is with Glassfish 3.1.2.2, Oracle JDBC non-XA DataSource pool.
>>>>
>>>> Thanks,
>>>>
>>>> -Noah
>>>>
--
Oracle <http://www.oracle.com>
Oracle Customer Services | GlassFish & Coherence Support
Steve Essery | Senior Principal Support Consultant
Phone: +44 1189 249508 <tel:+44%201189%20249508> | Mobile: +44 7748
112165 <tel:+44%207748%20112165>
TVP 540, Oracle Parkway, Thames Valley Park, Reading, RG6 1RA, United
Kingdom
ORACLE Corporation UK Ltd is a company incorporated in England & Wales |
Company Reg. No. 1782505 | Reg. office: Oracle Parkway, Thames Valley
Park, Reading RG6 1RA
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment