0
votes

I'm investigating what looks like a race condition in my Grails application. I occasionally see what I think can only be the result of 2 different threads interfering with one another when the application is under a lot of load.

The offending code builds a query using a closure (which is defined at class-level, like a method) which dynamically adds query parameters based on the properties of the domain class. On the surface the code looks fine (to me, as a Java developer), however I stumbled across this comment regarding controller scope in the Grails docs (emphasis mine):

prototype (default) - A new controller will be created for each request (recommended for actions as Closure properties)

session - One controller is created for the scope of a user session

singleton - Only one instance of the controller ever exists (recommended for actions as methods)

Reference

So my question is: what are the implications of using a closure (instead of a method) in a service which is a singleton?

EDIT:

The code is part of the grails quick search plugin:

https://github.com/tadodotcom/grails-quick-search/blob/master/grails-app/services/org/grails/plugins/quickSearch/QuickSearchService.groovy

There are 2 closures, aliasBuilder and propertyQueryBuilder which I think may not be thread-safe.

1

1 Answers

0
votes

Should you still need a solution, I just happened to fork that plugin and I stumbled upon the same problem (in the same concurrent scenario).

The long story short, helped by this post, I applied the @Synchronized annotation to the search method of QuickSearchService service and the exception (NPE btw) went away.

HTH