Re: concur

[James Clark <jjc@jclark.com>]

Kohsuke KAWAGUCHI wrote:

> Lazy evaluation is good in some cases, but it also has several problems.
> 
> * When one schema is shared among several threads, synchronization is
>   necessary, which severely hits the performance. This situation is very
>   common in the business application where tons of incoming orders have to
>   be validated.
> * In a long run, the table which memorizes patterns blows up. JTREX
>   suffers this problem, too.

I don't think these problems are inherent in lazy evaluation.

You need to have two distinct objects:

1. The pattern object

2. The lazily constructed automaton object

Multiple automaton objects may be associated with the same pattern
object.  Building the automaton does not mutate the pattern object.

Each thread can then have its own automaton object.  You can throw the
automaton object away and start with a fresh one when it gets too big,
or start a new one for each document to be validated. (I've been
wondering whether you can use java.lang.ref.WeakReference for this.)

It's slightly more tricky in JTREX since the automaton object (called
PatternBuilder) which holds the table that memoizes patterns is also
used in pattern construction.  I think the solution is to allow a
PatternBuilder to have a parent PatternBuilder.  When memoizing a
pattern, the child PatternBuilder checks to see whether the pattern to
be memoized it is already in the parent's table; if it is, it uses it
(which doesn't require modifying the parent PatternBuilder); otherwise
it puts it in its own table.

James