[ http://issues.apache.org/jira/browse/DERBY-815?page=comments#action_12364637 ]
A B commented on DERBY-815: --------------------------- > AB, the patch substitutes ArrayLists (not synchronized) for Vectors > (synchronized), so with > your MT-problems in mind I suggest we get a committer to revert the patch. Note that, as I mentioned in my previous comment, I am not able to say with certainty that the DERBY-815 patch is responsible for the intermittent hang--that has yet to be proven one way or the other. But that said, if you're okay with reverting the patch, I think I would prefer that since I have a lot of things on my plate right now and further investigation of this intermittent hang may not happen for another couple of days. > Maybe I can look at it again when you have committed your work. I'm not actively working on any changes related to this issue, so I don't think there's much point in waiting for me to "commit" something here ;) I do have a lot of things in progress, but none address this part of the code: I simply noticed that the ODBC tests I have are acting up after DERBY-815 was committed, and I was just following up in an attempt to find out why... If you are willing, I think the best thing here is to revert the patch for now, and re-submit it with 1) the fix for the regression, 2) the test case for the regression included as part of derbyall, and 3) some additional explanatory comments (per my last post). If you have time to investigate the multithreaded angle a bit , that would be _great_; if not, I think we could still commit an updated patch and I then can follow-up with more on the multithreaded test case when I have time. If it turns out that the DERBY-815 change are the cause (which we don't know yet), I can create another Jira issue with more details... Does that seem reasonable? > I must say that it seems very unlikey that DRDAStatements (which originally > contained > both Vectors and ArrayLists) can be shared between threads. If it worked > before it must be > by accident... That could very well be the case; I can't say for sure at this point. If you are in fact okay with reverting the patch and working on a revised version, please post here saying so, and then we can ask a commiter to back the change out. Thanks for your continued follow-up with this issue... > Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() > ----------------------------------------------------------------------------- > > Key: DERBY-815 > URL: http://issues.apache.org/jira/browse/DERBY-815 > Project: Derby > Type: Sub-task > Components: Network Server, Performance > Versions: 10.0.2.2, 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, > 10.1.3.0, 10.1.2.2 > Reporter: Knut Anders Hatlen > Assignee: Dyre Tjeldvoll > Priority: Minor > Fix For: 10.2.0.0 > Attachments: d815_regress.diff, d815_regress.java, d815_regress.stat, > d815_regress_derbyall_report.txt, derby-815.diff, derby-815.stat, > derbyall_report.txt > > Reported by Kathey Marsden in DERBY-212: > In reviewing the Network Server Code and profiling there were several > areas that showed potential for providing performance > improvement. Functions that need optimizing to prevent unneeded object > creation and excessive decoding: parseSQLDTA_work() -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
