If the units would be in minutes I think the odds that this bug would
surface in the wild would be quite slim unless the usecase would run very
long transactions.
On Fri, Nov 18, 2011 at 12:40 PM, Scott Marlow <smarlow(a)redhat.com> wrote:
I think the other part of the bug, is that connections shouldn't
"idle-timeout" if they are enlisted into a transaction (which I believe
should mean they are eligible for sharing).
In other words, I believe the following should work:
1. set idle-timeout-minutes=1 (currently this is 1 millisecond but 1
minute should also work).
2. JTA transaction begins.
3. Hibernate gets a non-xa resource X1 (database connection), enlists it
into the transaction.
4. Hibernate inserts a row into a database table using X1.
5. Hibernate closes X1 which shouldn't make X1 eligible for idle-timeout
handling, since it is still enlisted in the transaction.
6. Hibernate gets a non-xa resource, X1 should be returned. Imagine that
two minutes has elapsed since the transaction started, X1 should not be
idle-timed out.
7. Hibernate inserts another row into a database table using the resource
that should still be X1. If the resource is not X1, the "ARJUNA12140:
Adding multiple last resources is disallowed" error will occur.
8. The JTA transaction is committed successfully.
Maybe the IJ "idle-timeout" test case could simulate the above with a test
case that doesn't run always but maybe is run selectively. I think the
unit test will have to run for over a minute once the conversion error is
fixed (e.g. since idle-timeout-minutes will be treated as minutes instead
of milliseconds).
On 11/18/2011 02:18 AM, Nicklas Karlsson wrote:
> As a test, could you set idle-timeout-minutes=900000 (that should be 15
>
>> minutes).
>>
>> If changing the idle-timeout-minutes setting helps, could you create a
>> jira for that.
>>
>>
>> Indeed I can't see the issue after that
>
>
https://issues.jboss.org/**browse/AS7-2698<https://issues.jboss.org/br...
>
> ---
> Nik
>
>
--
---
Nik