I created the following JIRA:

https://issues.apache.org/jira/browse/ARIES-809

/Bengt

2012/1/15 Guillaume Nodet <[email protected]>

> 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