nk4um

Ok, I think I''ve found the cause:

It is possible to run more than one Saxon Processor concurrently, but only when running completely independent workloads. Nothing can be shared between Processor instances. Within a query or transformation, all source documents and schemas must be built using the same Processor, which must also be used to compile the query or stylesheet.

(see http://www.saxonica.com/documentation/javadoc/index.html)

I know make sure I only create one, a singleton.

Thanks for helping me zoom in on the problem!

Menzo

Hi Peter,

Thanks for your quick reply! I''ll use the safeDeepClone method as precaution. The DBX Engine is just a tool I''ve developed, which is heavily relying on Saxon. With two or more instances of the Engine I must violating some Saxon assumption then ... I''ll investigate that side of my code ...

Cheers,

Menzo

Hi Menzo,

I think you are finding that not having an immutable interface to DOM is a pain.

optxa.getReadOnlyDocument()

This method does not give you an immutable DOM - it gives you the underlying DOM and ReadOnly is our marker and is meant to signify "do not under any circumstances modify this object".

Unfortunately my bet is that the engine is writing to the DOM as part of its internal ops.  So a second thread coming in will get the same DOM but the engine has has violated the ROC immutability law.

The solution is to do a safeDeepClone

Before giving it to the engine.

Hope this helps.  I don''t know the tool your using so can''t offer any suggestions about if it would make sense to have a transreptor compile the operator to a reusable engine representation

Cheers,

Peter


[/url]

Hi, All,

I''m having some concurrency problems that I don''t understand.

I''ve an accessor which should be thread safe:

public class DBXEngine extends NKFAccessorImpl {    /** Creates a new instance of the DBX Engine */    public DBXEngine() {       super(4, SAFE_FOR_CONCURRENT_USE, INKFRequestReadOnly.RQT_SOURCE);    }    ... }

In the processRequest method I call the implementation of the actual DBX engine. This engine takes a script, called the guide, in the form of an XML document:

public void processRequest(INKFConvenienceHelper nk) throws Exception {       sloot.dbx.Engine engine = new sloot.dbx.Engine();              // get the NK request       INKFRequestReadOnly nkreq = nk.getThisRequest();              ...       IXAspect optxa = (IXAspect)nk.sourceAspect("this:param:operator", IXAspect.class);       engine.setGuide(optxa.getReadOnlyDocument());              IURAspect aspect = engine.run();       nk.createResponseFrom(aspect).setMimeType("application/xml");             }

Although I get the guide document as a ReadOnlyDocument this is the one that gets mangled when the accessor is concurrently called with the same guide document!  Am I making some basic mistake here? Any suggestion is welcome!

Thanks in advance,

Menzo