Bugzilla – Full Text Bug Listing
| Summary: | Smartfield does not show any result due to aborting of sql transactions | ||||||
|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Claudio Guglielmo <claudio.guglielmo> | ||||
| Component: | Scout | Assignee: | Project Inbox <scout.core-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | ivan.motsch, stephan.merkli | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows Vista | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
The behaviour that the smartfield got an error back to the ui could not be reproduced. However, I added a double check for interrupted exception in the LookupCall background handling. Please verify if that solves the issue. The fix seems to work with the swing ui. Thanks! However, with the SWT-UI the smartfield works well but aborting a server job is not possible anymore. This is because the job handling is different (unfortunately) in swt and swing ui. Since the HttpBackgroundJob is set to system=false, it is getting cancellable. The ClientSyncJob on the other hand which started the backgroundJob is set to system=true so actually not cancellable. However, the Swing-UI "ignores" these settings and does not cancel the http background job, instead the ClientSyncJob is canceled. The SWT-UI "only" cancels the http background job which does not lead to a cancellation of the server job (-> IServerProcessingCancelService.cancel() is never called). Additionally to that problem cancelling of a server job should not lead to an exception on server side. Otherwise the log gets spammed with exceptions only by using smartfields. Exception on server side: ... at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by: java.sql.SQLException: ORA-01013: Benutzer hat Abbruch des aktuellen Vorgangs angefordert at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) In Swing, the issue itself is fixed. But there is still one problem. The transaction abort is logged at the application server, which will cause the server log to grow. The preferred solution is not to log the abort in this case (because it's not an error here). For logging properties as used in Tomcat, there is no easy way to distinguish between this error and another SQL error. java.sql.SQLTimeoutException: ORA-01013: Benutzer hat Abbruch des aktuellen Vorgangs angefordert at org.eclipse.scout.rt.server.services.common.jdbc.internal.exec.StatementProcessor.processSelect(StatementProcessor.java:253) There is a problem with junit tests. If there is no transaction on the ThreadContext a NullPointerException will be thrown. In the Class StatementProcessor Line 1274ff in the Methods registerActiveStatement and unregisterActiveStatement. I'm not sure, if the junit test has to be corrected to create a new Transaction or the StatementProcessor the anticipate that there could be a case where no transaction is available (Nullcheck). Was able to reporduce the effect in swt. In fact the differerence between swt and swing is the way the cancelling job is determined. In swt scout (correctly) cancels the job with system=false, in swing it cancels the active ClientJob, regardless of the system flag. Fixed that in swing to behave same as swt. As a result the effect is reproducible in all environments. Fixed this by using the IServerProcessingCancelService.cancel result flag in the http background job to find out if the cancel was successful. if yes, the calling job is aborted with an interrupted exception. If no it simply continues. Fixed logging (comment 2,3,4) issue by checking for ITransaction.isCancelled() in DefaultTransactiohnDelegate when handling the transaction failure states. Added junit james tests server: CancelTransactionTest client: CancelLongRunningJobTest ticket closed. deliverd as part of eclipse scout 3.8.0 (juno release train) |
Created attachment 206341 [details] screenshot When using a smartfield with a lookup call and typing some text which leads to an execution of a sql statements on the server the client tries to cancel that execution some times (depending how fast you are typing). This is basically fine but it does not only cancel the execution of the sql but also throws an exception which leads to a processing fault and the smartfield does not show any result. This happens on trunk (3.8.0) Caused by: java.sql.SQLTimeoutException: ORA-01013: Benutzer hat Abbruch des aktuellen Vorgangs angefordert at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:452) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:400) at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:884) at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:471) at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:199) at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:535) at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:238) at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:1196) at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1444) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1662) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:4364) at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:4445) at oracle.jdbc.driver.OraclePreparedStatementWrapper.executeQuery(OraclePreparedStatementWrapper.java:6268) at org.eclipse.scout.rt.server.services.common.jdbc.internal.exec.StatementProcessor.processSelect(StatementProcessor.java:227) ... 63 more