tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: IllegalStateException: Cannot log transactions
Date Wed, 25 Jun 2008 05:44:14 GMT

On Jun 24, 2008, at 9:27 AM, Martin Vysny wrote:

> On Fri, 2008-06-20 at 20:11 -0700, David Blevins wrote:
>> On May 23, 2008, at 7:11 AM, Martin Vysny wrote:
>>> On Thu, 2008-05-22 at 22:31 -0700, David Blevins wrote:
>>>> On May 21, 2008, at 6:04 AM, Martin Vysny wrote:
>>>>> On Wed, 2008-05-21 at 14:18 +0530, Manu George wrote:
>>>>>> This looks like the XAResource that is being passed to the  
>>>>>> geronimo
>>>>>> transaction manager is not a named XA Resource. So transactions
>>>>>> will
>>>>>> not be logged in this case. I think you can open a JIRA as it  
>>>>>> looks
>>>>>> like a bug.
>>>> The crazy thing with this is that the HOWL transaction logging  
>>>> should
>>>> be off by default.  Looking at our defaults for the standalone
>>>> server,
>>>> it seems like we may have mismatching configuration defaults.   Tx
>>>> logging seems to be enabled in the TransactionManager by default
>>>> (MaxLogFiles=1) but shut off on the DataSource side
>>>> (TxRecovery=false), both should agree.
>>>> Adding this to your openejb.xml file should shut off tx logging and
>>>> make the error go away:
>>>> <TransactionManager id="TransactionManager">
>>>>     MaxLogFiles = 0
>>>> </TransactionManager>
>>>> Alternatively, setting the "TxRecovery" property to "true" on your
>>>> DataSources in the openejb.xml should turn on tx logging (for your
>>>> datasources at least) and should also make the error go away.
>>>> Let us know which way you go.  This will definitely be a good one  
>>>> for
>>>> the archives some docs should follow shortly.
>>>> -David
>>> Thanks for the tips, David!
>>> Setting the MaxLogFiles property to zero resulted in:
>>> 16:04:54,197 WARN  [main service] Property "MaxLogFiles" not  
>>> supported
>>> by "TransactionManager"
>>> and the exception was still visible in the log (OpenEJB3.0)
>>> Setting the TxRecovery property for the JDBC database Connector  
>>> fixed
>>> the error, and a warning has appeared instead. Better than an error
>>> indeed, however can I get rid of this warning as well? :)
>> Hi Martin, I've made a couple adjustments in this code.  If you could
>> give them a try that'd be great.
>> I've reworked all the flags for "TxRecovery".  Essentially I've added
>> it to the <TransactionManager> and removed it from the <Resource>.  

>> If
>> you set TxRecovery=true in the TransactionManager configuration then
>> the right magic should take place to setup the resources correctly --
>> i.e. you no longer need to configure a "TxRecovery" flag on them.
>> Update your poms to 3.1-SNAPSHOT or grab a snapshot distro:
>> The default for TxRecovery is false, so to test the recovery add this
>> to your openejb.xml:
>>  <TransactionManager id="TransactionManager">
>>      TxRecovery = true
>>  </TransactionManager>
>> This may not eliminate the "Unknown start flag" error, but it will
>> certainly narrow down the possible issues.  Let us know how it goes.
>> -David
> Hi David,
>  I checked out and compiled the revision 670607. The exception  
> vanished
> even without setting the TxRecovery flag to true. When I tried to set
> the TxRecovery flag to true the XAException appeared again:
> 18:25:43,493 WARN  [main Transaction] Unable to enlist XAResource
> org 
> .apache.geronimo.transaction.manager.WrapperNamedXAResource@1ba6b028,
> errorCode: 0
> javax.transaction.xa.XAException: Unknown start flag 2097152

I thought that might be the case.  Still trying to track down the  
issue.  We think it might be related to a connection leak reported and  
fixed by Jean-Francois.  I'll try and get some binaries whipped up  
that you can test.

> Thanks for fixing this bug :) When is the 3.1 version planned to be
> released?

Certainly the "bug" about being able to shut off HOWL transaction  
logging in an intuitive way is fixed :)  If you want that feature on,  
though, there's still one bug left to track down it seems.

On the release, the number will actually be 3.0.1 and I hope it won't  
be more than 3-4 weeks, but we won't know for sure till we spin up  
some binaries and start the Java EE 5 certification tests.


View raw message