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.)? 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
>>>
>>
>