Atomikos Forum

Hi

We are using Atomikos (latest realese) with Mysql 5.1, JMS (activeMQ 5.5), Spring (2.5.6) and Hibernate (3.6.4).

Everything is working fine except one thing : we get hundreds of this warning message in the logs :

[WARN ][timer][Slf4jConsole] Forcing close of pending statement: com.mysql.jdbc.jdbc2.optional.JDBC4PreparedStatementWrapper@1a704ea

I know it is just a warning message but beside creating huge server logs, I don't think it should generate these logs upon each successful request /commit! That is not "normal" behavior.

PS: Mysql is configured with as a XA DataSource

Our pattern is


userTransaction.begin()
hibernate open session
hibernate stuff on entities
userTransaction.commmit()
hibernate flush session
hibernate close session

So the questions is: where do these pending statements come from ??

How could I troubleshoot this ?? is it possible to view the sql statement of these statements ??

Any help appreciated!

I made an error, our pattern is :

hibernate open session
userTransaction.begin()
hibernate stuff on entities
hibernate flush session
userTransaction.commmit()
hibernate close session

maybe it is an hibernate related problem ... but i cannot go in production with all these warnings upon each commit !!!

please help !

Ok. After lot of troubleshooting, it seems that it may not be related to hibernate.

What is a "pending statement" for Atomikos ??

Most important: I see in the source code as soon as we create a statement on the JDBC connection it adds it in his statements list. But WHEN does it remove it ??

Here's what I found: as soon as we close the Connection from the DataSource (proxied by Atomikos) I see these warning messages. The thing is, Hibernate session is flushed and no operation is pending. Also, the statements seems to be empty.
These are com.mysql.jdbc.jdbc2.optional.JDBC4PreparedStatementWrapper and it wraps nothing! (underlying wrapped statement is null) I don't know really what is happening ...

A bug with MysqlDriver 5.1.16 and the XA DataSource ??

So for sharing :

I've reverted to using AtomikosNonXADatasourBean.
So one way or another, the MysqlXADatasource doesn't behave correctly with Atomikos.

I think it is related to proxying and the Mysql wrapper we see in the logs ...

If someone at Atomikos could check that it would be great.
Using Mysql Connector J 5.1.16 with Atomikos 3.7.0

thanks

Hi,

Did you try with the hibernate.connection.release_mode set to  after_statement?

Also see http://docs.jboss.org/hibernate/core/3.3/reference/en/html/session-configuration.html

HTH

Hi

Yes I did and it changed nothing.
The current behavior is :

1) With non XA mysql datasource, I see these messages only when rollbacking the transaction. Probably because hibernate kept open statements unflushed to the database.

This problem is related to Hibernate and we should have a way of clearing all those pending statements in Hibernate when/before rollbacking.

2) With XA mysql datasource, I see these messages for all executed statements. It seems the driver uses a kind of wrapper around Statement and that prevents in some way Atomikos to detect that the statements have been executed. So commit or rollback, I see hundred of these messages in the log.

This one is related to Mysql XA Datasource driver and Atomikos. I don't know what should be done but it prevents us form using an XA Datasource with Mysql and Atomikos.

Regards

Hello,

I am using Atomikos 3.7.0.

I do run into the same issue and much like Nicolas, I came to the same conclusion he did. Statements are added to a list and upon successful commit... forcefully closed with warning. The calls to the method closing the opened statements all have the "warn" parameter to true, except for the one which is called when closing the connection. This seems odd as it would suggest that every time one uses a transaction and commits it, one would need to close the connection to commit (!?). I think I may be missing something as it seems not logical to me both from the transaction point of view and the connection pooling point of view.

If you want to look at it the class where the logging happens is AbstractConnectionProxy and the method forceCloseAllPendingStatements (L 53). I think the method's name is erroneous as there seem to be no other ways to get these statements out of this list and close them... Also there are references to cases numbers (31275 and 73007) which would be nice to be able to consult but I do not know how and where... and google does not know either.

I do not think that it would help for these but there seem to be a new version of the lib out (3.7.1). I will try it out.

Finally, I did try to upgrade MySQL connector "just in case" and very logically it solves nothing (it would have been very surprising given my previous statements).

Thank you for looking into it,

I will post again after trying the newer version of Atomikos.

Regards,

Good morning,

I was wrong there is no 3.7.1 (or at least I cannot find it).

Regards,

Hello
I was suffering this problem also. Reviewing atomikos documentation about Hibernate integration I realized that we were using the standard Hibernate TransactionManager lookup class instead of the one provided by Atomikos.

After adding the following property in my configuration

hibernate.transaction.manager_lookup_class=com.atomikos.icatch.jta.hibernate3.TransactionManagerLookup

the staments are correctly closed before transaction commit.

Hi,

I've already configured the TransactionManagerLookup class this way. Are you using the MysqlXaDataSource ??

The symptom is mostly present when using the XA DataSource.
When using non XA data source, I only see these statements when doing a Rollback ...

Hello,

I do use the correct TransactionManagerLookup for the property hibernate.transaction.manager_lookup_class in my hibernate configuration.

This is still an open issue for me as it forces me to set the log4j level to ERROR or have humongous log files... It is also hard to tell what is a real WARNING from what is not.

Thank you in advance for looking into it.

Regards,

Hi Slorg1,

So what value for hibernate.transaction.manager_lookup_class are you using?

Thanks

Hi Guy,

I use : TransactionManagerLookup.class.getName()

Where TransactionManagerLookup is com.atomikos.icatch.jta.hibernate3.TransactionManagerLookup.

I hope that helps.

Thank you in advance,

Regards,

It's been a while - let me try to summarize:

-commits leave too many warnings in the logs

Possible solutions:

1-your code or config closes statements when they are no longer needed

2-we change our implementation to avoid the warnings

Personally I prefer 1: it is bad practice to keep Statements pending, because you are using DBMS server-side memory resources along with each such Statement.

What do you think?

Hi Guy,

When you say "your code or config closes statements when they are no longer needed". I think you are wrong because with no code change, switching for Mysql XA datasource from Mysql NON XA datasource solves the problem.

So I think the problem is between come from the Mysql JDBC driver or the integration of Atomikos with Mysql. Since you are saing that Mysql is supported, you should try to see what's wrong with mysql XA datasource with latest mysql connector and fix it in your code or ask mysql to fix it.

It is in no way our coding / configuration that causes this problem. I don't think Hibernate is involved either since I am using it the same way and switching between Mysql datasources causes the problem.

Regards.

Hi,

I made a note to consider option 2 - but please be careful when considering non-XA behavior as the norm. It is not really intended for production use - XA should be preferred.

In any case, closing the connection (with hibernate settings) after each statement should prevent this from what I can tell.

Thanks

I'm seeing the same messages, even though the statements are closed.

I'm probably missing something, but this looks like a bug.  As Nicholas wrote on May 27, AbstractConnectionProxy.addStatement() is called when statements are created, but nothings seems to remove them from the list except for forceCloseAllPendingStatements(), and the latter method doesn't check if statements are already closed.