That would be me. :) So here's how the system is setup. This is basically a GUI front end to a build environment and the GUI (using GWT+Jython) is just displaying the information in the database. Somewhere else (on various build machines) are python scripts that are updating the database. There is no communication between the python scripts and the GUI front end. So the pieces of this system aren't actually using the same cursor because all the pieces have their own database connection.

On Tue, Aug 24, 2010 at 5:44 PM, Chris Clark <Chris.Clark@ingres.com> wrote:

I suspect you are focusing on; "A reference to the operation will be retained by the cursor." This is really talking about avoiding re-preparing queries or allocating new cursors on each execute. Using the same cursor/query against the same table (after a commit of data) should return different data. Most (good) CPython DBI drivers do the same thing.

I really would be surprised if this was a zxjdbc issue. Maybe have a chat with your DBA?

Chris



Jeff Levesque wrote:
It will take me a little bit to make a test case for this but the documentation for execute in PyCursor contains the follow:

   /**
    * Prepare and execute a database operation (query or command).
    * Parameters may be provided as sequence or mapping and will
    * be bound to variables in the operation. Variables are specified
    * in a database-specific notation (see the module's paramstyle
    * attribute for details).
    *
    * A reference to the operation will be retained by the cursor.
    * If the same operation object is passed in again, then the cursor
    * can optimize its behavior. This is most effective for algorithms
    * where the same operation is used, but different parameters are
    * bound to it (many times).
    *
    * For maximum efficiency when reusing an operation, it is best to
    * use the setinputsizes() method to specify the parameter types and
    * sizes ahead of time. It is legal for a parameter to not match the
    * predefined information; the implementation should compensate, possibly
    * with a loss of efficiency.
    *
    * The parameters may also be specified as list of tuples to e.g. insert
    * multiple rows in a single operation, but this kind of usage is
    * deprecated: executemany() should be used instead.
    *
    * Return values are not defined.
    *
    * @param sql sql string or prepared statement
    * @param params params for a prepared statement
    * @param bindings dictionary of (param index : SQLType binding)
    * @param maxRows integer value of max rows
    */

I was just unable to follow how it works or determine if there was a way to disable this mechanism.

On Tue, Aug 24, 2010 at 4:52 PM, Chris Clark <Chris.Clark@ingres.com <mailto:Chris.Clark@ingres.com>> wrote:

   Jeff Levesque wrote:

       I've written an API in Python that works in both CPython for
       scripting and Jython in combination with a GWT front end but
       I'm having issues with some database results. It seems like
       something is caching the database results when I'm using
       Jython. I've read through the ConnectorJ documentation and
       tried disabling all the caching options I could but it doesn't
       seem to have made any difference. Is it possible zxJDBC is
       caching the results or just not passing options I set to JDBC?
       Any help would be much appreciated.


   It is more likely to be the JDBC driver (or dbms) doing the
   caching than zxjdbc (I've not seen zxjdbc do any caching, with
   defaults).

   Can you switch drivers/backends to test that idea out? You could
   for instance be doing repeatable reads (transactions) or some
   other DBMS specific (rather than zxjdbc) thing.

   Making a small 10 line script test case is your best bet.

   Chris