groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blake McBride <blake1...@gmail.com>
Subject Re: Re-entrant and multi-entrant Groovy calls
Date Fri, 20 Apr 2018 15:03:30 GMT
Yes, it is calling a static method on a Groovy class.  Is there a problem
with what I am doing in term of re-entrant or multi-entrant interference?

Thanks.

Blake


On Fri, Apr 20, 2018 at 8:16 AM, Wolfgang Pedot <wolfgang.pedot@finkzeit.at>
wrote:

> I dont know, your code looks like it is calling a static method on a class.
>
> What I was referring to was using something like
> GroovyScriptEngine.createScript and reusing the returned Script-Object.
>
> Wolfgang
>
> Am 20.04.2018 um 14:32 schrieb Blake McBride:
>
>> Every time I call Groovy from Java I do the following code snippets.
>> Does this have the problem you are referring to?
>>
>> public void runGroovy(String fileName) {
>>      JSONObject injson = ...
>>      JSONObject outjson = ...
>>      HibernateSessionUtil hsu = ...
>>
>>      GroovyClass gclass =loadClass(fileName,true);
>>      if (gclass !=null) {
>>          Class[] ca = {
>>                  JSONObject.class,
>>                  JSONObject.class,
>>                  HibernateSessionUtil.class,
>>                  HTMLFlex.class };
>>
>>          try {
>>              @SuppressWarnings("unchecked")
>>              Method methp = gclass.getMethod(_method, ca);
>>              if (methp ==null) {
>>                  errorReturn(response,"Method " + _method +" not found in
>> class " +this.getClass().getName(),null);
>>                  return;
>>              }
>>              methp.invoke(null, injson, outjson, hsu,this);
>>          }catch (Exception e) {
>>              errorReturn(response,"Error running method " + _method +" in
>> class " +this.getClass().getName(), e);
>>              return;
>>          }
>>      }else {
>>          errorReturn(response,"Error loading " + fileName,null);
>>          return;
>>      }
>> }
>> public synchronized static GroovyClass loadClass(String fileName, boolean
>> report) { GroovyClass gclass; *[some class cacheing code]*try { gclass =
>> new GroovyClass(false, fileName); classCache.put(fileName, new
>> ClassInfo(gclass, (new File(fileName)).lastModified())); } catch
>> (FileNotFoundException e) { if (report) logger.error("File " + fileName + "
>> not found", e); return null; } catch (Exception e) { if (report)
>> logger.error("Error loading " + fileName, e); return null; } return gclass;
>> }
>>
>>
>>
>> On Fri, Apr 20, 2018 at 7:15 AM, Wolfgang Pedot <
>> wolfgang.pedot@finkzeit.at <mailto:wolfgang.pedot@finkzeit.at>> wrote:
>>
>>     For Groovy-scripts you need to know that each instance of a script
>>     has a Binding to store variables in it and that may cause
>>     re-entrance or concurrency issues if you dont create a new script
>>     instance for each call.
>>
>>     Wolfgang
>>
>>     Am 20.04.2018 um 11:21 schrieb Blake McBride:
>>
>>         Greetings,
>>
>>         Does Groovy safely support re-entrant and multi-entrant calls?
>>         What I mean by that is the following:
>>
>>         Re-entrant: on a single OS thread - my Java program calls into
>>         Groovy, then Groovy calls into my Java application, and then
>>         the Java application calls back into Groovy. So the stack has
>>         Java, Groovy, JAVA, and then Groovy again.
>>
>>         Multi-entrant: my Java application has many threads.  One of
>>         my threads calls into Groovy. Then, while one thread is still
>>         in Groovy, another thread evokes Groovy. So now we have two
>>         calls into Groovy by two independent Java/OS threads running
>>         at the same time.
>>
>>         I understand the typical problems associated with
>>         application-level shared variables.  This is expected.  The
>>         question revolves around Groovy's internals.  I presume Groovy
>>         may have some shared data that is internal to Groovy. That's
>>         what I am unclear about. Groovy would have had to be designed
>>         for these scenarios from the ground up.
>>
>>         This is a little hard to test because if it can't always
>>         correctly handle these situations, it may not become clear
>>         until certain scenarios arrive.  It may be hard for any "test"
>>         program I write to cause those scenarios, so I thought this
>>         may be a known answer.
>>
>>         Thanks!
>>
>>         Blake McBride
>>
>>
>

Mime
View raw message