Thilo is correct - I was thinking about the non-remote case ....
-Marshall
Thilo Goetz wrote:
Marshall Schor wrote:
Philip Ogren wrote:
In the tutorial there is a section titled "Retaining references to
JCas objects between calls to process()" which tells you not to retain
references to JCas objects.
JCas objects (as well as non-JCas Java cover objects you get using the
non-JCas methods) are tiny objects that refer to data in an associated
CAS. If that CAS still has the data, you can retain these references.
If the CAS is reset, and then perhaps refilled subsequently with other
data, these old references could still point into the CAS, but what
they'd be pointing to would be meaningless.
This is why this advice is given.
If for instance, you do your own custom application which loads and
calls a series of annotators, passing a common CAS among them, it's fine
to hold onto JCas (or non-JCas Java) references you might have in the
application, over the set of process() calls. Just be sure to not use
the references, once you've reset the CAS.
I hope this clarifies things a bit.
-Marshall
Well, even in the scenario described above, there can be times when
it is not possible to hold on to CAS/JCas references. This can be true,
for example, when the CAS is serialized/deserialized during processing,
when doing a remote call. The internal references in the CAS may change
completely, so external pointers into the CAS are no longer valid.
So I would never hold on to JCas references across process calls. It
can cause all sorts of hard to debug problems.
There are discussions on the OASIS TC to guarantee "constant IDs" in the
future, which would guarantee the integrity of references across process
calls, but the current implementation makes no such claims.
--Thilo
