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

acefael commented on GROOVY-7673:
---------------------------------

marking the class non thread-safe would limit its utility quite a lot, to me.
in a threaded environment one would have to resort to creating and discarding 
Sql instances a lot,
which in turn casts doubt on the built in caching mechanisms.

I understand that, in a multithreaded environment, and when using Sql with a 
data source, any implicit state ought to be avoided, including the updateCount 
and prepared statements.  There's a performance penalty through that, which 
cannot be avoided.

When using the Sql with a j.s.Connection it can cache all it wants and be 
therefore non thread-safe.

Perhaps that's the distinction?  Thread safe with a DataSource, non thread-safe 
with a Connection?

[keyColumnNames|https://github.com/apache/incubator-groovy/blob/22c749fea5c41fdb89d4739ec9a2249d97de58cc/subprojects/groovy-sql/src/main/java/groovy/sql/Sql.java#L268]
 appears to me another candidate for concurrency issues.


> groovy.sql.Sql race condition?
> ------------------------------
>
>                 Key: GROOVY-7673
>                 URL: https://issues.apache.org/jira/browse/GROOVY-7673
>             Project: Groovy
>          Issue Type: Question
>    Affects Versions: 2.4.5
>            Reporter: acefael
>
> I am using groovy.sql.Sql with a commons dbcp2 BasicDataSource and am 
> encountering a stacktrace as in \[2\] below.  I do create many identical 
> closures with different data, and I pass them all at once to 
> ExecutorService.invokeAll.  The closures are all using the same Sql instance.
> I believe this is a race condition because it happens only when the database 
> is over a network, and not when the database is local.
> To work around I can set Sql.cacheNamedQueries = false.  Problem is reliably 
> gone in this case.  So I guess the culprit is in \[1\], with my sql already 
> being cached in namedParamSqlCache, but not yet in namedParamIndexPropCache?
> \[1\] the line in the source code
> https://github.com/apache/incubator-groovy/blob/GROOVY_2_4_X/subprojects/groovy-sql/src/main/java/groovy/sql/Sql.java#L4407
> \[2\] the stacktrace
> {noformat}
> > java.lang.NullPointerException
> >       at java.util.ArrayList.<init>(ArrayList.java:168) ~[?:1.8.0]
> >       at groovy.sql.Sql.buildSqlWithIndexedProps(Sql.java:4422) 
> > ~[groovy-all-2.4.5.jar:2.4.5]
> >       at groovy.sql.Sql.checkForNamedParams(Sql.java:4369) 
> > ~[groovy-all-2.4.5.jar:2.4.5]
> >       at groovy.sql.Sql.getPreparedStatement(Sql.java:4360) 
> > ~[groovy-all-2.4.5.jar:2.4.5]
> >       at groovy.sql.Sql.getPreparedStatement(Sql.java:4439) 
> > ~[groovy-all-2.4.5.jar:2.4.5]
> >       at groovy.sql.Sql.execute(Sql.java:2366) ~[groovy-all-2.4.5.jar:2.4.5]
> >       at groovy.sql.Sql.execute(Sql.java:2438) ~[groovy-all-2.4.5.jar:2.4.5]
> >       at groovy.sql.Sql$execute$1.call(Unknown Source) ~[?:?]
> >       at es.acefael.BaseMigration.execute(BaseMigration.groovy:2017) 
> > ~[es-acefael-dostuff-SNAPSHOT.jar:?]
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to