One feature i'd like to keep from the current tx mgr, is that it's exposed
as a Spring tx mgr too which helps when using spring.  Other than that I
dont't have much problem.


On Friday, January 13, 2012, David Jencks <[email protected]> wrote:
> I bet I know what's going on... setting the tx timeout only applies to
that thread and the next transaction on that thread.  There's a default
transaction timeout milliseconds that can only be set in the tm
constructor.  This is not a suitable model for osgi configuration.
> In my geronimo sandbox I refactored the tm so it has better osgi
structure.  Maybe we should work to release that.  It would pretty much
replace the aries tm.
> david jencks
> On Jan 13, 2012, at 7:34 AM, Bengt Rodehav wrote:
>
> I have now tested to sleep 650 s which exceeds the default transaction
timeout of 600 s. This gives me an exception due to transaction timeout.
Thus Geronimo transaction timeout works.
> I then configure the transaction timeout to 30 s (in the manner I've
described previously) and sleep for 60 s in order to force a transaction
timeout. I don't get a transaction timeout.
> To be sure I then checked to see if the configuration was bound and it
wasn't! I had just made a fresh start of Karaf (by deleting the bundle
cache). I also tried doing a refresh but the configuration was still
unbound. I then restarted Karaf (without clearing the bundle cache) and
after that the configuration was bound.
> However, even after my configuration was bound the test I did still did
not provoke a transaction timeout.
> I think there must be something wrong with the way Aries transaction
picks up its configuration - perhaps some timing issue.
> Also, even when the configuration is bound, it still doesn't seem to
affect the transaction manager. Perhaps the transaction manager is created
to soon and then not recreated when configuration updates are pushed by
config admin?
> Can anyone explain this? Has anyone been able to configure the
transaction manager at all?
> /Bengt
>
> 2012/1/13 Bengt Rodehav <[email protected]>
>
> David,
> That test is almost identical to what I did in my code. The difference is
that I don't explicitly access the transaction manager like you do. I use
blueprint to make my method transactional (with the "Requires" transaction
attribute) and I configure the transaction timeout via Config Admin.
> I never doubted that Geronimo's transaction timeout worked but I wonder
if Aries is setting the properties correctly. I will make a test where I
sleep for longer than the default timeout (600 s) to see if that would
trigger an exception. If so, then the problem is how to configure the
timeout correctly.
> /Bengt
>
> 2012/1/13 David Jencks <[email protected]>
>
> 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]>
>

-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Reply via email to