Saxon

Legacy ID: #6478322 Legacy Poster: Michael Kay (mhkay)

Java serialization of compiled queries (unlike XSLT stylesheets) is not supported. It works for XSLT stylesheets, but there is really no benefit in using it; it doesn't save any time over recompiling from source, and the amount of data to be moved to the client is likely to be much larger. Note that it wouldnt' be enough to simply serialize and deserialize; the mechanism also has to adjust the compiled code to enable it to be used with a different NamePool.

Legacy ID: #6509839 Legacy Poster: Sudhir (sudhirdumbre)

Thanks Michael for the reply. I will explain problem in detail . I have client-server architecture.On the server we compile nearly 300 xqueries.When clients starts each clients requires to have all xquieries.In current senario each client has to recompile all the xqueries on start of client side application. i want to remove this step by sending xqueryExpression from server to client .This is possible in Saxson9 as Xqueryexpression is serializable. I am using functx-1.0-doc-2007-01.xq for functions.For this i am importing this library using statement "import module namespace functx = "http://www.functx.com" at c:xq\functx-1.0-doc-2007-01.xq ;" in all xquery files. If i remove the import satement and functx functions from xquery files then it is serializable otherwise it throws error like "java.io.NotSerializableException" for object "net.sf.saxon.om.NamespaceResolverForElements" while starting the client application. is it possible to do above.Appreciate your help. thank you

Legacy ID: #6511259 Legacy Poster: Michael Kay (mhkay)

I understand. It might be that some compiled queries are serializable, but this is untested and unsupported, and as you have discovered, other queries are not serializable; and even for those that can be serialized, this is of no use because the form of the compiled query is tied to a particular NamePool.

Legacy ID: #6511296 Legacy Poster: Michael Kay (mhkay)

As an alternative approach, try the facility to compile queries to Java code. This is available only in Saxon-SA. Moving and loading the compiled Java code should be much more efficient than serializing and deserializing the internal (interpreted) form of the query, and the code has no dependencies on the configuration in which it was compiled.

Legacy ID: #6524110 Legacy Poster: Sudhir (sudhirdumbre)

Thanks Michael for quick response. Saxon-SA being licensed version i need to discuss with higher authority. I appreciate your help and time spent on this problem. Can you please elobarate the point you made in last reply that "this is of no use because the form of the compiled query is tied to a particular NamePool" Thank you.

Legacy ID: #6524284 Legacy Poster: Michael Kay (mhkay)

>Can you please elobarate the point you made in last reply that "this is of no use because the form of the compiled query is tied to a particular NamePool" The Saxon NamePool (which is owned by the Configuration object) holds integer codes for QNames, and is used for fast matching of nodes in a source document. For example the query "//item" might be compiled into code that searches for all nodes whose nameCode is 17952. Because the integer name codes are held in the source document, this makes searching very fast. But it means that the codes allocated when compiling the query must be the same as those used when building the source document, and this will only be the case if the query compilation and the building of the source document are done under the control of the same namePool. The facility for serializing compiled XSLT stylesheets deals with this problem by rebuilding the original NamePool when it is deserialized. A consequence is that you can't run two reconstructed stylesheets in the same Configuration, which means you can't run them against the same source document.