DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Andy Jefferson
Reporter: Frank Mallezie
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
DataNucleus Store RDBMS

SQL-queries in a J2EE-environment (weblogic 10.3) raise a nullpointerexception

Created: 13/Aug/10 09:21 AM   Updated: 20/Oct/10 09:30 AM   Resolved: 23/Sep/10 02:57 PM
Component/s: Queries
Affects Version/s: 2.0.5
Fix Version/s: 2.2.0.m2

Environment: Weblogic 10.3

Datastore: Oracle
Severity: Development

 Description  « Hide
We have set up datanucleus in weblogic 10.3 using the jca-connector datanucleus-jca.rar
We use datasources and the thin Oracle jdbc-driver.

We execute an sql-query like this:

  Query query = pm.newQuery("javax.jdo.query.SQL", "SELECT DISTINCT USAGE FROM
                              DOCUMENTSOORT ORDER BY USAGE");
  results = (Collection) query.execute();

In the line 'query.execute()', we get a NullPointerException in the method getMetadata() of class weblogic.jdbc.wrapper.ResultSet.

After some investigation, I found that the resultset (java.sql.ResultSet rs) was reset because the resultset was created in another thread (and transaction) than the current thread.

The creation of the resultset is done in, method performExecute(Map parameters): (lines 275)
     // Execute the query as a task so we can allow timeout/cancel
     ResultSet rs = (ResultSet)performExecuteTask(new Object[] {sqlControl, mconn, ps});

I changed this lines to the following, and then the query is executed

             ResultSet rs;
                  rs = sqlControl.executeStatementQuery(mconn, compiledSQL, ps);
             catch (SQLException sqle)
                  throw new NucleusDataStoreException(LOCALISER.msg("059025", compiledSQL), sqle);

If you need more information, do not hesitate to ask.


Sort Order: Ascending order - Click to sort in descending order
Erik Bengtson added a comment - 12/Sep/10 11:46 AM
bea/oracle recommends that you use the oracle driver and not the weblogic wrapper.

When you configure the driver, ensure that you use the oracle one.

Frank Mallezie added a comment - 13/Sep/10 09:17 AM

As noted in the description of this issue, we used the 'thin oracle driver', NOT the weblogic wrapper.
So, I don't agree with your comment


Andy Jefferson added a comment - 23/Sep/10 02:28 PM
Saying that something being created in a different thread causes issues in Oracle's JDBC driver is obviously an Oracle problem, since it is an acceptable practice to make use of threads for handling data retrieval.

The "fix" to DN code is certainly not just to strip out any use of threading, since that then negates use of query/cancel APIs and obviously won't happen. Better would be to just provide a persistence property to execute queries in the same thread when required (default = execute in separate thread) and accept that the query/cancel API is no longer available.

Andy Jefferson added a comment - 23/Sep/10 02:57 PM
SVN trunk allows specification of persistence property
with default of true. The same is available as a query extension flag for each query. No idea if this works on WebLogic, and no testcase was provided anyway

Fernando Padilla added a comment - 30/Sep/10 10:38 PM
I happen to be reviewing the code, and wonder if there would be a cleaner way to do this.

Instead of having the check be within JDOQLQuery and JPQLQuery, why not have it inside Query itself?

At the top of Query.performExecuteTask(), you would add:

if ( !executeInSeparateThread() ) {
  return performExecuteInternal( args );

just an idea.. i guess you could argue on the exact pros/cons of this suggestion. :)

ps - i saw a performExecuteTask for BulkUpdate/BulkExecute, shouldn't those have the executeInSeparateThread check as well??