The switch doesn't modify any CAS - stored Feature Structure content. It does modify what JCas cover class is used when, for instance, iterating over some type in the CAS.
Say, for example, you have implemented a JCas cover class for Token, which just has some standard getters and setters. Now, suppose, one of the pipelines implements a Pear which has an "enhanced" version of the Token JCas class. For example, it might look up the "stem" word in some dictionary, and have a list of synonyms available, not stored in the CAS, but via an extra API "fancysynonyms()". Now, suppose this CAS is read only, and there are two thread operating on it; both with this Pear, where the code isn't going to modify the CAS, but within the Pear, will iterate over the Tokens, and will call "fancysynonyms()". Now imagine the time-linear flow for two threads that looks like this: Thread 1: start -----------> enter Pear -----> access fancysynonyms ---------> exit Pear ------> etc. Thread 2: start -----------> enter Pear --------------------------------------------------> access fancysynonyms ---------> exit Pear ------> etc. Thread 1's "exit Pear" will have switched the CAS's jcas loaders back to the "plain" one., so thread 2's iterator over Token would be returning the plain version of the Token JCas class which would get a class-cast-exception when the code tried to cast it to the fancy version of the Token JCas class. At this point, I'm in favor of saying that you cannot use any classpath switching with read-only shared CASs. This includes Pears, and the edge case in UIMA-5054 where the switching was to an "outer" class loading context. -Marshall On 8/19/2016 6:24 AM, Richard Eckart de Castilho wrote: > I haven't every used read-only CASes and have no idea how they are > implemented. > ... or maybe I'm just failing to make the mental connection to something I > remember > by a different name. > > Your explanation seems to imply that the classloader switch might somehow lead > to some threads being able to modify the CAS and thus circumventing the > read-onlyness? > > Cheers, > > -- Richard > >> On 18.08.2016, at 18:47, Marshall Schor <m...@schor.com> wrote: >> >> The Pear support was done before we contemplated read only CASes. >> >> Even though a CAS is read only, when you get Feature Structures (FSs) via >> iterating, those FSs are made into Java cover class instances, according to >> a) >> whether or not the JCas is being used, and if it is, b) what "set" of JCas >> cover >> classes is currently active. >> >> Within a Pear, there can be different definitions of some JCas cover >> classes. >> The code "switches" the JCas set when crossing the Pear boundaries, as the >> pipeline is executing. >> >> >> This switching is not thread-safe. So (currently) a read-only CAS being >> operated on by thread T1 containing a Pear would switch to use the Pear's >> JCas >> definitions while perhaps another thread T2 not containing a pear, was >> iterating. This would (currently) cause T2 to start getting JCas cover class >> instances from the Pears's JCas definitions. >> >> Not sure how to proceed. On the one hand, we could keep Pear information on >> a >> "per thread" basis in thread local data. This perhaps might slow things >> down a >> bit (not sure). On the other hand, we could "outlaw" the use of Pears in >> read-only CAS situations (not sure how to detect this, though). >> >> It probably isn't a real problem (yet) because these are unusual ways to >> operate; I'm guessing that the applications doing shared read-only CASes are >> not >> using Pears, and vice versa (so far). >> >> Opinions welcomed :-) -Marshall >> >
