[ 
https://issues.apache.org/jira/browse/OFBIZ-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17748442#comment-17748442
 ] 

Paul Foxworthy edited comment on OFBIZ-12836 at 7/28/23 7:57 AM:
-----------------------------------------------------------------

[~jleroux] wrote:
??I get this message "The 'isAfterLast' method is only allowed on scroll 
cursors." Is that normal ? Actually why did you change resultMessage content???

I thought we could save a variable by just asking the resultset if it was after 
the last row or not. But it appears that isAfterLast only works if you have set 
the ResultSet type to         TYPE_SCROLL_INSENSITIVE or TYPE_SCROLL_SENSITIVE, 
and not if it's TYPE_FORWARD_ONLY.

For what we are doing, it's overkill to fuss about the type of the resultset. I 
have reverted to the previous code where we used an additional variable to 
track whether or not we reached the end of the results.

I have also added a package and rerolled the patch for the new location now 
OFBIZ-12813 has been committed


was (Author: paul_foxworthy):
[~jleroux] wrote:
??I get this message "The 'isAfterLast' method is only allowed on scroll 
cursors." Is that normal ? Actually why did you change resultMessage content???

I thought we could save a variable by just asking the resultset if it was after 
the last row or not. But it appears that isAfterLast only works if you have set 
the ResultSet type to         TYPE_SCROLL_INSENSITIVE or TYPE_SCROLL_SENSITIVE, 
and not if it's TYPE_FORWARD_ONLY.

For what we are doing, it's overkill to fuss about the type of the resultset. I 
have reverted to the previous code where we used an additional variable to 
track whether or not we reached the end of the results.

> Resource leaks in EntitySQLProcessor.groovy
> -------------------------------------------
>
>                 Key: OFBIZ-12836
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-12836
>             Project: OFBiz
>          Issue Type: Bug
>          Components: webtools
>            Reporter: Paul Foxworthy
>            Assignee: Paul Foxworthy
>            Priority: Minor
>         Attachments: EntitySQLProcessor-1.groovy, 
> EntitySQLProcessor-2.groovy, EntitySQLProcessor.groovy, 
> Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-1.patch, 
> Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-2.patch, 
> Fixed__Resource_leaks_in_EntitySQLProcessor_groovy-3.patch, 
> Fixed__Resource_leaks_in_EntitySQLProcessor_groovy.patch
>
>
> In framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy at line 
> 35 
> [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L35]
>  
> it creates an SQLProcessor. SQLProcessor has a Close method and implements 
> AutoCloseable, but we're not using try-with-resources, nor directly calling 
> the Close method.
>  
> Similarly,
>  
> [https://github.com/apache/ofbiz-framework/blob/e080f0bfa657b8b6ffd4cbf5629e0c648440b5f0/framework/webtools/groovyScripts/entity/EntitySQLProcessor.groovy#L38]
>  
> obtains a java.sql.Resultset, which will be closed when everything works, but 
> would leak if there was an exception. Again, we should be using 
> try-with-resources.
>  
> Note that according to 
>  
> [https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/ResultSet.html#close()]
>  
> "Calling the method close on a ResultSet object that is already closed is a 
> no-op.", if you obtain a ResultSet from the SQLProcessor and directly close 
> that ResultSet, it's not a problem when the SQLProcessor.close also attempts 
> to close the ResultSet.
>  
> The problem is minor, most of the time. The groovy script is in the webtools, 
> so used for developer tinkering and not production use.
>  
> When you're doing a SELECT, the script is closing the ResultSet, so the 
> important resources are cleaned up (assuming no exception occurred).
>  
> However, if you are doing INSERT, UPDATE or DELETE, the script creates a 
> prepared statement that is not closed, so there's a resource leak.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to