Community
Participate
Working Groups
Attached stack trace from the server. After this stack trace, comes other exceptions like DB lock timeouts or SQlIntegrityConstraintViolationException.
Created attachment 190173 [details] StackTrace
It looks like interruption more likely is caused by the "org.eclipse.emf.cdo.internal.server.QueryManager.QueryContext.cancel". It by it self calls "future.cancel(true)", which should trigger this exception. Fix could be to call "future.cancel(false)", without interrupting running thread - letting to finish DB call thread
Derby is such a trouble maker!
Well, no, actually. Derby (although being slooow) does most of the things really right, which should be expected from most DMBS, but that are optimized away. (e.g., transactional table/schema manipulation). Therefore, things that cause exceptions in Derby are potentially able to cause hard-to-debug inconsistencies in other DBMS which don't complain as much. So, up to some point, we should be grateful that Derby helps us detect some of these things ;-)
I see ;-)
I hope you're grateful that I assigned this bug to you :P
Created attachment 190245 [details] Patch v1 Patch proposal. It is hart to see, if it is enough, but taking all facts together I think it should be right way. Let the future do not interrupt running task, what do you think?
Message from Derby forum, which could give background for this fix: http://mail-archives.apache.org/mod_mbox/db-derby-user/201103.mbox/%3Cx6bp1ule8f.fsf@oracle.com%3E
Stefan, does the attached patch look reasonable to solve issue?
(In reply to comment #9) > Stefan, does the attached patch look reasonable to solve issue? At first glance: yes. At the same time, I also see the issue that if you do a long-running query with a QueryContext and you call cancel then the long-running query will continue to run nonetheless. So, we are buying a better behavior with Derby (and potentially other DBMS who cannot cope with thread interruptions) for the sacrifice of not being able to interrupt long-running queries on the DB at all. Question: Could we introduce an optional flag (something like "boolean alsoCancelInStore") into the QueryContext's cancel API, which provides a hint to the store implementor that it should also interrupt DB queries. Then it's up to the application developer to decide which of the options above is desired.
> Question: Could we introduce an optional flag (something like "boolean > alsoCancelInStore") into the QueryContext's cancel API, which provides a hint to > the store implementor that it should also interrupt DB queries. Then it's up to > the application developer to decide which of the options above is desired. IMO, if we would have possibility to configure, then it is even better.
Created attachment 191809 [details] Patch v2 As per earlier discussion, behavior is now configurable.
Please add a section to http://wiki.eclipse.org/CDO/Server_Configuration_Reference#Element_repository
Committed revision 7579.
Wiki updated.
Available in R20110608-1407
