Caucho Forums  

This forum is permanently closed because of spam. For free community support, please visit Google Groups:


Go Back   Caucho Forums > Quercus

Reply
 
Thread Tools Display Modes
  #1  
Old 12-04-2012, 09:35 AM
Maddy09 Maddy09 is offline
Junior Member
 
Join Date: Jun 2011
Posts: 4
Exclamation PDO MySQL Doesn't work as expected

I use Quercus on glassfish 3.1 and for 90% is works absolutely G R E A T.
So a huge compliment for that at first.

But..

I use the PDO way for interactions with MySQL and there are some flaws in that construction.

My Code example:
PHP Code:
function getSome() { 
always try...
PHP Code:
try { 
PHP Code:
$dbh=null
PHP Code:
$dbh = new PDO("java:comp/env/jdbc/blablabla"); 
1. This is what i tried to get any error to be raised and cached:
PHP Code:
$dbh->setAttribute(PDO::ATTR_ERRMODEPDO::ERRMODE_EXCEPTION); 
ok, this works as expected
PHP Code:
$stmt=$dbh->prepare("select * from tablename"); 
PHP Code:
$stmt->execute();$rows= $stmt->fetchAll(PDO::FETCH_ASSOC); 
2. Now we shutdown $dbh, at least i hoped it would
PHP Code:
$dbh=null
PHP Code:
do something with the data... 
PHP Code:
3. this is never triggered
PHP Code:
  catch(PDOException $e) 
PHP Code:
  
4. never will be called
PHP Code:
   echo $e->getMessage(); 
PHP Code:
    
PHP Code:
So what i saw was:
1. No mather which error MySQL generates or what happens,
PHP Code:
  catch(PDOException $e) 
will never be triggered. No error has ever been seen or written here.
I had multiple errors and i always had to use other code to give me the errors.

2.
PHP Code:
$dbh=null
never works. It is all handled by Glassfish and when i do a huge insert or update on multiple rows i end up with 1000+ open connections to MySQL and at the end the code fails on to many open connections error.
And this to many conenctions error is not printed anywhere. It just generates this error:
Quote:
[#|2012-12-04T11:06:52.808+0100|INFO|glassfish3.1.1|javax.ent erprise.system.std.com.sun.enterprise.server.loggi ng|_ThreadID=24;_ThreadName=Thread-2;|11:06:52,801 ERROR [PHPPortlet:209] Error processing PHP
com.caucho.quercus.QuercusException: com.caucho.quercus.QuercusException: com.caucho.quercus.QuercusErrorException: /liferay/glassfish-3.1.1/domains/domain1/applications/my-portlet/includes/functions2.inc.php:101: Fatal Error: 'execute' is an unknown method of false.
It took several hours to find out it was a caused by to many connections in MySQL.
I already raised some jdbc connections to 2000+ connections at once, but it's kind of mad to do so.
Reply With Quote
  #2  
Old 12-04-2012, 01:12 PM
nam nam is offline
Administrator
 
Join Date: Aug 2009
Posts: 337
Default

Hi,

Let me explain what's going on. Quercus does not do reference counting, so it does not know when there are no more references to an object. Therefore, $dsh=null does NOT close the connection in Quercus. To close the connection, you'll need to call the Quercus-specific method: $dsh->close().

As for the PDOException, I filed a bug report for it at:
http://bugs.caucho.com/view.php?id=5301
Reply With Quote
  #3  
Old 12-04-2012, 01:14 PM
nam nam is offline
Administrator
 
Join Date: Aug 2009
Posts: 337
Default

Also, if you don't manually close the connections, Quercus will automatically close connections at the end of the request. But if a request uses a lot of connections, you'll still run out of connections (as you've witnessed).
Reply With Quote
  #4  
Old 12-05-2012, 03:28 PM
Maddy09 Maddy09 is offline
Junior Member
 
Join Date: Jun 2011
Posts: 4
Default

I accidently just found the $dbh-close(); yesterday after i posted my complaint.

I solved the errorcode handling by
PHP Code:
$theError=$stmt->errorInfo(); if (isset($theError[1])){    resin_debug(": Error->".$theError[2]);    } 
Reply With Quote
  #5  
Old 12-05-2012, 03:38 PM
Maddy09 Maddy09 is offline
Junior Member
 
Join Date: Jun 2011
Posts: 4
Default

Quote:
Quercus will automatically close connections at the end of the request.
Well not on glassfish, withing Glassfish the JDBC manager will control the moment of releasing the connection if you do not use $dbh-close();.
And that is a real pain to create the right settings for the JDBC.

I have some scripts that have to walk 100+ tables multiple times and then the amount of open connections exceeded the 1000 after a couple of seconds.

Setiing a smaller time-out (like 3 seconds) on the JDBC connection in glassfish gives you an quicker release but if the database is very busy it sometimes takes more than 3 seconds to get all the data back from the query and then glassfish just cuts the wire to MySQL which results in an error in PHP/PDO.

I don't know where it is caused, but i noticed that during the running of such a script something seems to buffer the queries. If i start the script by opening a php-page it takes some seconds before the queries are fired to the database. Even with very simple pages with no fancy rendering i could see that the script runs and runs and then *boom* 500 connections fly to the MySQL database. (this ofcourse only when i didn't use the close() statement)

I must say it looks quite impressive to see such an amount of queries flying in within 2 or 3 seconds. That wouldn't be seen anyway with standard PHP.
Reply With Quote
  #6  
Old 12-05-2012, 04:03 PM
nam nam is offline
Administrator
 
Join Date: Aug 2009
Posts: 337
Default

Quote:
Setiing a smaller time-out (like 3 seconds) on the JDBC connection in glassfish gives you an quicker release but if the database is very busy it sometimes takes more than 3 seconds to get all the data back from the query and then glassfish just cuts the wire to MySQL which results in an error in PHP/PDO.
Wow, Glassfish is just crazy then.
Reply With Quote
Reply

Tags
glassfish, mysql, pdo

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 12:41 PM.


Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.