Thread: [Php-java-bridge-users] Persist Open JDBC Connection

Hi,

How would you persist an open JDBC connection across invocations of the same
PHP script but at different times, from different computers?

For example the following does not work:

    // Load the PostgreSQL database driver.
    //
    java( 'java.lang.Class' )->forName( 'org.postgresql.Driver' );

    $conn = apc_fetch( $PERSIST );

    if( $conn === false || $conn->isClosed() ) {
      echo "Reloading JDBC connection: $conn\n";
      exit;

      // Attempt a database connection.
      //
      $conn = java( 'java.sql.DriverManager' )->getConnection(
        "jdbc:postgresql://$dbhost/$dbname?user=$dbuser&password=$dbpass" );

      // Failure to add is fine; it means the above fetch will fail, and
      // thus recreate the JDBC connection each time. Not ideal; might have
      // a performance impact.
      //
      apc_delete( $PERSIST );
      apc_store( $PERSIST, $conn );
    }

The $conn is always closed after the script ends.

The only other way I can think of to prevent this from happening is to
implement my own PostgreSQL Connection subclass, and override "close()" to
do nothing.

The problem I'm trying to solve is that the PG database reloads PL/R modules
for each new database connection.

What I need is some sort of persistent JDBC connection pool for the PHP-Java
bridge.

Any ideas?

Thank you!
Dave

Hi Dave,

> How would you persist an open JDBC connection across invocations of the same

PHP is essentially a "shared nothing" architecture. However, you can
store Java objects into the Java session using

   java_session()->put("key", $jVal)

where $jVal is a java object implementing java.io.Serializable.


> For example the following does not work:

Of course not. Your other PHP script might be running on a different
server. Even if there's only one server, you may have more than one
java back end (see option <distributable/> in your web.xml.

You must guarantee that $jVal is available to all PHP instances.
Either use a 3 tier architecture, or make your java session
distributable or use only one java back end and store your value
there.

I don't know if your $jVal is distributable. If it's not, use a
standard 3 tier architecture.

Since we are talking about jdbc drivers; jee uses its own connection
pool. So the only thing you'll have to do is to fetch a connection
from the pool, for example by using standard JNDI lookups.


Regards,
Jost Boekemeier

Hi,

java_session()->put("key", $jVal)
>
where $jVal is a java object implementing java.io.Serializable.
>

Looks like PGConnection and its derivatives cannot be serialized (without
changing the API). The only serializable interface is
PGConnectionPoolDataSource.

Unless there are any other ways to persist the JDBC connection, it looks
like I'm going to have to abandon this optimization for now.

Of course not. Your other PHP script might be running on a different
> server. Even if there's only one server, you may have more than one
> java back end (see option <distributable/> in your web.xml.
>

One web server running Apache2 -- no web.xml files, no j2ee.

Thank you for your suggestions.

Dave

> One web server running Apache2 -- no web.xml files, no j2ee.

The PHP/Java Bridge requires a JEE application server or servlet
engine as a back end.

The procedure for MySQL and Tomcat is described here:
http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html#Database%20Connection%20Pool%20%28DBCP%29%20Configurations


Regards,
Jost Bökemeier

Hi, Jost.

Thanks for the post. I'm running the bridge in Standalone mode, and
PostgreSQL is the database.

Dave

Hi!

> Thanks for the post. I'm running the bridge in Standalone mode

so you are running a Java desktop application and use the bridge to invoke methods of your desktop app?

If so, your application probably uses a jdbc connection pool. If not, it's not your task (as a PHP programmer) to add one.


Peter






      

Hi,

so you are running a Java desktop application and use the bridge to invoke
> methods of your desktop app?
>

Not exactly; there is no desktop application per se. The code that opens the
JDBC connection and generates the report, using PHP and the bridge, is as
follows:

  try {
    $params = report_parse_post_parameters();

    // Load the PostgreSQL database driver.
    //
    java( 'java.lang.Class' )->forName( 'org.postgresql.Driver' );

    // Attempt a database connection.
    //
    $conn = java( 'java.sql.DriverManager' )->getConnection(
      "jdbc:postgresql://$dbhost/$dbname?user=$dbuser&password=$dbpass" );

    // Use the fill manager to produce the report.
    //
    $fm = java('net.sf.jasperreports.engine.JasperFillManager');
    $pm = $fm->fillReport($report, $params, $conn);

    header('Cache-Control: private');
    header('Content-Description: File Transfer');
    header("Content-Disposition: attachment, filename=$filename.pdf");
    header('Content-Type: application/pdf');
    header('Content-Transfer-Encoding: binary');

    java_set_file_encoding('ISO-8859-1');

    $em = java('net.sf.jasperreports.engine.JasperExportManager');
    $result = $em->exportReportToPdf($pm);

    $conn->close();

    header('Content-Length: ' . strlen( $result ) );
    echo $result;
  }

The JasperReports library is on the classpath when the bridge is started. I
was trying to keep the *$conn* variable open for the next request. But that
would probably lead to all kinds of nasty business.

I suppose could add a connection pool and serialize that, instead.

When I get a bit more time, I'll try it.

Thanks, Peter.

Dave

Hi,

> Not exactly; there is no desktop application per se.

please see our FAQ entry "Do I need a JEE application server or
servlet engine?" :
http://php-java-bridge.sourceforge.net/pjb/FAQ.html

>> The procedure for MySQL and Tomcat is described here:
>> http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.html#Database%20Connection%20Pool%20%28DBCP%29%20Configurations

> PostgreSQL is the database

Not relevant. See the bottom of the document.


Regards,
Jost Boekemeier