Nirva Application Platform

Hi Lionel,

Nirva properly closes all the database connections owned (opened) by a session when this one terminates. Adding an explicit DATABASE:SOURCE:CLOSE would not change the problem. The issue seems to be a know one for the linux mysql odbc driver but should have been corrected in version 5.1.9 of the driver. Now I suspect that there is still some instability in this part of the driver.
There is nothing we can do at this level on the database service itself.
You can try to play on the mysql parameter for time outs. You can also try to "refresh" the existing connections using a Nirva listener in order to avoid them going into time out. You can set the odbc trace file to see if there is some specific context where this problem occurs.
In the Nirva context, database connections can be opened by a thread and closed by another one and maybe the driver doesn't manage correctly that.
You can try the following tests in order to attempt reproducing the issue: open a database connection from a named session created at application start time, then try to close and re-open this db connection. If it works, do the same but after changing the time out of mysql connection (on mysql side).
We'll try to do the same tests on our side.
Question, do you have the same issue on a 32 and 64 bits environments ?

Thank you Pierre for your answer.

I'll try to do the test in the morning, and will keep you posted.

We have the same issue on both 32 and 64 bits environments.

I reproduce now the issue on a "simple" test. It involves sessions names, and several threads using the same ODBC connection I guess.

After several tests, I finally added the property Threading = 2 to the driver in the odbcinst.ini file to turn multi-threading off at the ODBC manager level, but the message still occures.
I have not tried the timeouts, since I am able to reproduce the bug in 1 procedure execution (few seconds). I believe it has nothing to do with the timeout.

I also parametrized log files, but they don't display any error.

I'm afraid that the problem really is about the driver not handling correctly the fact that a thread opens a connection, and another thread closes it.

At this step, it should be usefull to try reproducing the issue outside the Nirva context area in order to post a bug report to mysql. I can do that but I need to be sure of the origin of the issue and to do some tests before. How do you reproduce it with the minimum material ?

Attached to this message is an application package containing a minimalist way to reproduce the problem.

• test_db_open: script to close and open a database connection
• test_db_parallel_tasks: script that asks for a named session and calls previous script in the named session
• test_db_named: script that asks for a named sessions and calls script to close and open database connection in it. It also calls in threads the previous script 2 times to simulate several concurrent connections.

• Linux 32bits (We had a similar issue on a Linux 64bits environment, but I have not tested this application on it)
• ODBC configuration for MySQL using the latest ODBC connector (5.1.10)
• Nirva Server launched with -c -v and -t parameters

• Install the attached application
• In a browser, enter URL: http://localhost:1081/nv_app_BUG_ODBC/NVS?Command&NV_CLOSE_SESSION=YES&NV_SESSION_OPEN=a&NV_SESSION_CLOSE=b&NV_XML_SUBCONTAINERS=YES&NV_PROC=perl:test_db_named
• The warning message (Error in my_thread_global_end(): xx threads didn't exit) should be displayed in the console. If not, stopping the application should display it.

Thank you very much for your help!

Hi Lionel,

Thanks for your code to reproduce the issue. I was able to reproduce it on my side. This error is not a Nirva error so I will not post a bug for it. This is a mysql odbc driver error. In fact the driver displays the message "Error in my_thread_global_end()" when a thread is opening a connection and another one is closing it. This situation may occur with Nirva especially when using database connection pool with named sessions.
We are going to post a bug report to MySql. For now, we cannot validate this driver with Nirva. There is a MySql driver provided by DataDirect but it's not free. We will test it and come back to you.
I attach a zip file containing a small program to reproduce the issue on linux. The usage is "testodbc2 -s DataSource -u User [-p Password]".

Hi Pierre

Thank you for your help.
I confirm your little program reproduces the bug on my environment.

I will look for DataDirect solutions.
Thank you for your help

Juste for information, here is a link to the mysql bug: http://bugs.mysql.com/bug.php?id=64466