![]() |
![]() |
|
Erik,
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 Frank 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. SVN trunk allows specification of persistence property
"datanucleus.query.executeThreaded" 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 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?? |
|||||||||||||||||||||||||||||||||||||||||
When you configure the driver, ensure that you use the oracle one.