On 10/1/07, Danai Wiriyayanyongsuk <[EMAIL PROTECTED]> wrote:
> Hi Adam,
>
> Thanks again for the clarification. I really appreciated it :)
>
> Speaking of Case1 testing, did your two testing annotators get the same
> Session object reference? Mine did. Actually, by not using PEAR class loader
> in Case1, both of my annotators consistently got the same Session object
> reference for all three AnalysisEngine instances in the AnalysisEnginePool
> of a MultiprocessingAnalysisEngine_impl instance.
>

Ah - the AnalysisEnginePool is the missing piece of information.  I
incorrectly assumed that you had two *different* annotators in an
aggregate, in which case they would have different Session objects.
In your case you have multiple instances of the same annotator, and
they should share the Session object (that is the intended purpose of
the Session object).

So now I'm on the same page with you - the Session object will be
shared as long as you don't use PEAR components.  PEAR components are
always isolated from one another, even within an AnalysisEnginePool.
So this is the same basic issue as was just opened in JIRA yesterday.


> Anyway, given the limitation/behavior of PEAR isolated class loader, which
> approaches/practices would you recommend to share an object, say a large
> array of bytes, between each annotator that run in its own PEAR isolated
> class loader?
>

I think unfortunately the only options are to use the CAS or to use
static fields.  If the data doesn't change per document then the CAS
isn't an ideal place to put it.  Static field could work (assuming
that all classes shared by the annotators are in the application class
path, not the annotators' individual class paths).

Static fields are inflexible in that you can't then run multiple
instances of your same annotator class that *don't* share the same
resource within the same JVM.  But I don't see a better option at this
point.


-Adam

Reply via email to