Atomikos Forum

Forcing close of pending statement

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!
Nicolas Bourdeau Send private email
Thursday, May 26, 2011
 
 
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 !
Nicolas Bourdeau Send private email
Friday, May 27, 2011
 
 
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 ??
Nicolas Bourdeau Send private email
Friday, May 27, 2011
 
 
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
Nicolas Bourdeau Send private email
Friday, May 27, 2011
 
 
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
Guy Pardon Send private email
Friday, June 03, 2011
 
 
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
Nicolas Bourdeau Send private email
Friday, June 03, 2011
 
 
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,
Slorg1 Send private email
Friday, June 24, 2011
 
 
Good morning,

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

Regards,
Slorg1 Send private email
Monday, June 27, 2011
 
 
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.
César García Send private email
Thursday, July 07, 2011
 
 
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 ...
Nicolas Bourdeau Send private email
Thursday, July 07, 2011
 
 
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,
Slorg1 Send private email
Thursday, July 07, 2011
 
 
Hi Slorg1,

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

Thanks
Guy Pardon Send private email
Wednesday, July 13, 2011
 
 
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,
Slorg1 Send private email
Thursday, July 14, 2011
 
 
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?
Guy Pardon Send private email
Monday, July 25, 2011
 
 
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.
Nicolas Bourdeau Send private email
Monday, July 25, 2011
 
 
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
Guy Pardon Send private email
Monday, July 25, 2011
 
 
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.
Youval Send private email
Wednesday, September 14, 2011
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics