[
https://issues.apache.org/jira/browse/DERBY-4771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12969506#action_12969506
]
Dag H. Wanvik commented on DERBY-4771:
--------------------------------------
Hi Kristian, thanks for addressing my comments. Here:answers to your questions
in connection with my latest batch of comments:
> * Yes, but not at this level. I thought it would be nice to have a name for
> the transaction to identify it in the transaction table. I think some new
> methods must be added to be able to name a transaction at this level, so I'm
> not sure if it is worth the trouble. I'm keeping the TODO for now, might
> remove it in the next iteration.
>
> Opinions?
Fine with me.
> * It isn't needed now. Since the interface is internal, and there is only one
> implementation of it, I suppose the best action to take now is to remove it.
> We can introduce it again later, and then probably in a shape more like you
> have described. It feels a bit odd to say in the JavaDoc that scheduling
> requests may be denied, and not have a way to learn if it happened or not...
>
> Opinions?
Fine, too.
> * Added synchronization for runningThread in the finally-block. The current
> code will let the thread die and then create a new one on the next update
> request. I considered adding a sleep before letting the thread die, in case a
> new request would come in quickly.
> Opinions?
I guess this could be improved later if it turns out to be an issue. +1
> * Do you mean we should call TransactionResourceImpl#handleException
> explicitly here?
> I think the comment meant to say that the daemon will be disabled
> elsewhere. I'll address this issue in the next iteration.
Great.
> * I think I meant to retry the whole operation, that is to add the unit of
> work to the end of the queue or something. The way it is now, it will retry
> to get the locks, but if that fails it will discard the unit of work. Note
> that there is retry logic on several levels here. Since a new unit of work
> will be scheduled the next time a query using the index(es) is compiled, I'll
> delete the TODO and keep the code as it is. If this strategy turns out to be
> inadequate, we can fix it later.
Ok, fine.
> Continue investigation of automatic creation/update of index statistics
> -----------------------------------------------------------------------
>
> Key: DERBY-4771
> URL: https://issues.apache.org/jira/browse/DERBY-4771
> Project: Derby
> Issue Type: Task
> Components: SQL, Store
> Affects Versions: 10.8.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Attachments: autoindexstats.html,
> derby-4771-1a-prototype_code_dump.diff,
> derby-4771-1a-prototype_code_dump.stat,
> derby-4771-1b-prototype_code_dump.diff,
> derby-4771-2a-prototype_lcc_code_dump.diff,
> derby-4771-2b-prototype_lcc_code_dump.diff,
> derby-4771-2c-prototype_lcc_code_dump.diff,
> derby-4771-2d-prototype_lcc_code_dump.diff, DERBY-4771-2e-prototype.rar,
> derby-4771-2e-prototype_lcc_code_dump.diff,
> Derby-4771-2f-AutomaticIndexStatisticsTest_wondows7.rar,
> derby-4771-2f-prototype_lcc_code_dump-WORK-IN-PROGRESS.diff,
> derby-4771-2f-prototype_lcc_code_dump.diff,
> derby-4771-2g-prototype_lcc_code_dump.diff,
> derby-4771-2h-prototype_lcc_code_dump.diff, derby.log, error-stacktrace.out,
> rjall.out, rjall.out, rjall.out, rjall.rar, rjone.out
>
>
> Work was started to improve Derby's handling of index statistics. This issue
> tracks further discussion and work for this task.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
