Bug #71679 Avoid iterator creation when invoking statement interceptors in MysqlIO.

Description:
In the methods MysqlIO#invokeStatementInterceptorsPost and MysqlIO#invokeStatementInterceptorsPre an iterator is used to loop over the list of statement interceptors. As far as I can tell, the list of the statement interceptors is always an ArrayList. So using the old-school for-loop should be the preferable way there to loop over the list. Even if the Hotspot would allocate the iterator on the thread's stack (and he does that), I think MySQL Connector/J should still avoid creation of the iterator, because the size of the thread stack is limited and I would prefer to see that objects from my application are allocated on the stack and not those from MySQL Connector/J.

One more thing. I won't submit a patch for this. But could you please review the method ConnectionImpl#isSameResource(Connection), lines 4030-4031:

                                if (!nullSafeCompare(otherOrigDatabase, this.origDatabaseToConnectTo)) {                        directCompare = false;
                                        directCompare = false;

I think the assignment "directCompare = false;" in the line 4030 can be removed. :-)

How to repeat:
See my patch.

Suggested fix:
Use the old-school for-loop to iterate over the list.

Patch for this issue.

Attachment: MysqlIO.patch (application/octet-stream, text), 1.78 KiB.

Hi Andrej,

Thank you for this bug report. Verified by code review.
Thanks for noticing the duplicated line too.

Patch for this issue.

(*) I confirm the code being submitted is offered under the terms of the OCA, and that I am authorized to contribute it.

Contribution: MysqlIO.patch (application/octet-stream, text), 1.78 KiB.

Thanks Andrej, accepted.

Added the following entry into the Connector/J 5.1.30 changelog:

"Avoided the use of an iterator over the list of statement interceptors in the methods MysqlIO.invokeStatementInterceptorsPost() and MysqlIO.invokeStatementInterceptorsPre(), so that Connector/J does not increase the stack size unnecessarily."