On Jan 12, 2012, at 11:08 PM, Bengt Rodehav wrote:
> David, do you think I should create a JIRA for this? I don't know for sure
> whether I'm doing anything wrong or not but I think it makes sense to add an
> integration test for the transaction timeout anyway.
I looked and geronimo has a timeout test like this:
public void testTimeout() throws Exception
{
long timeout = tm.getTransactionTimeoutMilliseconds(0L);
tm.setTransactionTimeout((int)timeout/4000);
tm.begin();
System.out.println("Test to sleep for " + timeout + " millisecs");
Thread.sleep(timeout);
try
{
tm.commit();
fail("Tx Should get Rollback exception");
}catch(RollbackException rex)
{
// Caught expected exception
}
// Now test if the default timeout is active
tm.begin();
System.out.println("Test to sleep for " + (timeout/2) + " millisecs");
Thread.sleep((timeout/2));
tm.commit();
// Its a failure if exception occurs.
}
So I tend to think timeout works. Is what's tested for here what you observe
in your code?
thanks
david jencks
>
> I'm currently just using one resource manager (SQL Server 2005) which I guess
> means that no transaction log is necessary. Thanks for explaining.
>
> /Bengt
>
> 2012/1/13 David Jencks <[email protected]>
>
> On Jan 12, 2012, at 1:26 PM, Bengt Rodehav wrote:
>
>> I took a look at the transaction related itests and I can't see any tests
>> regarding the transaction timeout - they seem to be focused on testing the
>> transaction attributes. Could it be that the transaction timeout has never
>> been tested?
>
> probably not in aries since the tm implementation is from geronimo. I did
> think there were some osgi tx timeout tests but I dont have access right now.
>
>>
>> Regarding the transaction log I'm not sure how this is supposed to work -
>> perhaps someone can enlighten me. Shouldn't every transaction be written to
>> a transaction log file?
>
> Every successfully prepared transaction with at least two participating
> resource managers will have a log record written for prepare and another
> written for commit. Transaction with only one participant don't need logging.
>
> thanks
> david jencks
>
>>
>> /Bengt
>>
>> 2012/1/12 Bengt Rodehav <[email protected]>
>>
>> David,
>>
>> I have verified that the configuration is applied to the transaction service
>> I just can't see that it has any effect. I guess I can start debugging but I
>> was hoping to avoid that. Do you know if there are any integration tests
>> that tests the transaction timeout?
>>
>> /Bengt
>>
>>
>> Den torsdagen den 12:e januari 2012 skrev David
>> Jencks<[email protected]>:
>>
>> > I would guess that perhaps your configuration is not actually getting
>> > supplied to the managed service? If you are running in karaf you can use
>> > confiig:list to make sure config admin is aware of your config. You might
>> > also want to debug the aries code and make sure that the configuration is
>> > actually getting supplied to the service.
>> > david jencks
>> > On Jan 12, 2012, at 6:36 AM, Bengt Rodehav wrote:
>> >
>> > Hello again Alasdair,
>> > I finally got around to test configuration of Aries Transaction. I created
>> > the following configuration (using PID org.apache.aries.transaction):
>> > aries.transaction.timeout=1
>> > aries.transaction.howl.logFileDir=${karaf.data}/txlog/
>> > I set the logfile directory as well as the transaction timeout (I peeked
>> > at how they do it in Servicemix). I set the timeout to a low value in
>> > order to test that I actually get a transaction timeout. I also perform a
>> > 5s sleep in a transacted method to force a transaction timeout.
>> > But, I never get a transaction timeout and I never get a transaction log
>> > file in the "logFileDir" directory. I'm not beginning to fear that my
>> > methods are not transacted. How can I verify this?
>> > Under what circumstances would a transaction log file be created? I
>> > assumed that it would be created when the first transaction was created.
>> > Or, do I also need to add the following line?
>> > aries.transaction.recoverable=true
>> > I've tried that but still no logfile was created.
>> > I also noticed that the default value for
>> > "aries.transaction.howl.maxBuffers" is 0 while the default value for
>> > "aries.transaction.howl.minBuffers" is 4. Is that correct? At first sight
>> > I would think it should be the other way around.
>> > /Bengt
>> >
>> >
>> >
>> >
>> >
>> >
>> > 2011/12/29 Bengt Rodehav <[email protected]>
>> >
>> > Thanks Alasdair - will look into it.
>> > /Bengt
>> >
>> > 2011/12/28 Alasdair Nottingham <[email protected]>
>> >
>> > Hi,
>> > The pid for configuring transactions is "org.apache.aries.transaction".
>> > Alasdair
>> >
>> > On 14 December 2011 14:33, Bengt Rodehav <[email protected]> wrote:
>> >
>> > It turned out that my error was not due to the transaction timing out but
>> > to violation of unique constraints. Nevertheless, I would like to know how
>> > to control the transaction timeout in Aries transaction.
>> > /Bengt
>> >
>> > 2011/12/14 Bengt Rodehav <[email protected]>
>> >
>> > Thanks for your reply David,
>> > I'll see if I can figure out the pid although this seems like something
>> > that really needs to be documented in Aries. If the default timeout is 600
>> > seconds then this is probably not the reason of the errors I see. I need a
>> > time out of about 30 s which then is much less than the default.
>> > I have been using MySql but I'm in the process of switching to SQL Server
>> > 2005. MySql worked fine but I started having problems committing the
>> > longer transactions with SQL Server 2005 which caused me to suspect a
>> > transaction timeout. Perhaps the timeout is not propagated to SQL Server
>> > like you hinted.
>> > /Bengt
>> >
>> > 2011/12/14 David Jencks <[email protected]>
>> >
>> > Transaction is set up as a managed service factory. I haven't figured out
>> > exactly how this results in a tm instance without any visible
>> > configuration.
>> > If you can figure out what is triggering the creation of a tm and the pid,
>> > the property to set is called aries.transaction.timeout and the default
>> > value is 600 (seconds) or 10 minutes.
>>
>
>
