Support #5124

Unexpected error "Cannot read a document that was written during the same transformation" - race condition

Added by Johan Gheys 5 days ago. Updated 3 days ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:


We use Saxon-EE 10.5 and one of our transformations is giving for the first time the unexpected error "Cannot read a document that was written during the same transformation" (see log file error-2021-10-12.txt). A simple restart fixed the problem. Probably seems closely related to issue 4934?

error-2021-10-12.txt (36.4 KB) error-2021-10-12.txt Johan Gheys, 2021-10-13 10:10
shared-functions.xslt (66.2 KB) shared-functions.xslt Johan Gheys, 2021-10-13 10:11
select-trains-and-movements-(proxy).xslt (15.3 KB) select-trains-and-movements-(proxy).xslt Johan Gheys, 2021-10-13 10:11

Related issues

Related to Saxon - Bug #5130: `saxon:discard-document()` should be synchronizedResolved2021-10-15

<a title="Actions" class="icon-only icon-actions js-contextmenu" href="#">Actions</a>


#1 Updated by Michael Kay 3 days ago

The first sign that things are wrong here is the message

Some child xsl:result-document threads have not finished

which should never happen.

Before that there are three messages of the form

*** MISSING file:/var/opt/app/arte2/u00p/interfac/exporter/publish/20211012-1726/formation/88_movement_HE_527.xml

which might well provide a clue.

The message

XTRE1500  Cannot read a document that was written during the same transformation:

is actually a little inaccurate. It happens on a doc() call when the URI passed to doc() is unavailable, either because it was previously written using xsl:result-document, or for a variety of other reasons. The immediate cause is that the URI is present in a controller-owned collection called (misleadingly) allOutputDestinations, which is updated not only by xsl:result-document but also by fn:doc() and saxon:discard-document(). I suspect that if two threads both call doc() and subsequently call saxon:discard-document() on the same URI then it might be possible for the URI to be left in this collection at the end.

I'll need to think about that possibility a bit more carefully. If I'm right, then I think the only solution might be to introduce a function (say saxon:doc(uri, map{'stable':false()}) that's equivalent to doing doc() followed by discard-document(), but does it as an atomic action.

In fact I see that the implementation of saxon:discard-document() isn't even synchronised within itself, which it certainly should be. That's easy to fix, but whether it's enough to solve the problem I don't know.

None of this explains the disquieting message Some child xsl:result-document threads have not finished. Is that something you see elsewhere in your log files?

#2 Updated by Michael Kay 3 days ago

I raised bug #5130 regarding synchronization of saxon:discard-document(). It's quite hard to know whether that's actually a contributor to the current problem, but it's worth fixing anyway.

#3 Updated by Michael Kay 3 days ago

  • Related to Bug #5130: `saxon:discard-document()` should be synchronized added

#4 Updated by Johan Gheys 3 days ago

Hi Michael, thanks for the investigation. Every $runs/run is creating an xsl:result-document (see line 27 of select-trains-and-movements-(proxy).xslt) and I thought that error message was the result of an earlier problem (probably the reading problem caused by saxon:discard-document()) like you suggests).

Please register to edit this issue

Also available in: Atom PDF