Node Level insertions analysis.

After a couple of weeks of fighting with Tamino’s Java APIs to do node level insertions, I have come to the following comments. Please, if someone here finds my assertions to be wrong, PLEASE post your comments.

Background:
- App. Server: I am using Tomcat 4.0.2 (Catalina) running on a Windows 2000 Professional machine. Running Java 1.4 and Xerces 2.0. Clients connect using http port 8080, no proxying.
- DB Server: Tamino on Windows 2000 Server, SP2, single CPU machine. Running Tamino 3.1.1.1 using IIS.

What I did: tried both ways of node insertion in a document that I already have in the database.

The document I have is about 343,783 bytes. The inserted node is about 42K.

Had Tamino installed and after reading the QA guide posted by Bill Leeney found that I was using an old version of MS XML. Installed MS XML 4.0 (guide says it will work with any version later than 3.0). – this is important, read section for Java HTTP API –

Using Java API:

Tamino DOESN’T support node level insertions using the Java API, therefore you have to get the entire document, insert your node and then send the entire document back to the server.

In my setup it took 3375 ms. to insert 43,476 bytes. This is the time elapsed to insert the node in memory and update+commit it on the server.


Using Java HTTP API:

Using this method, you call appendChild on the TaminoClient class. You must give a document and an XPath. The following are suggestions that may save you many many hours of work:

- NodeLevelUpdate.dll doesn’t work with MS XML 4.0. It works only with MS XML 3.0. If you have ver. 4.0 it will rise an Unhandled Exception and will kill inetinfo.exe; killing your connectionwith the client (client will show a connection refused exception). So use MS XML 3.0 SP2.

- You MUST use docuverse implementation when appending a node in your document. The reason for this is because the API uses the Node.toString() method to send the XML over the network. If you use xerces, you will be sending [nodename:null] over, which will not work. So, get your node, re-parse it and create an instance of a docuverse document and use this instance to send it to the server. Not sure if that is a DOM Level 2 vs. Level 1 problem. Docuverse doesn’t support importNode method, therefore you have to convert your XML in a String and re-parse it using docuverse implementation. Any suggestions?

- For me, it didn’t work using the root access (/) for the XPath, I had to use the indirect access (//) method. That means that an xpath of /Data didn’t work for me, I had to use //Data; which in theory is less efficient.

- If you run into troube, use TaminoClient.setTrace(true) method and you will see what is being sent to the server over HTTP.

- When I was querying a wrong document I didn’t get any answer from the server, just an empty response. So I guess that when there is an error, you receive nothing.

In my setup, it took about 3,364 ms. to store 42,239 bytes using appendChild. This is the time it took between the appendChild + commit operations on TaminoClient.

NOTES:

- The document sizes are measured as the size of their string representation.


QUESTIONS:

- Since you can go either way, what would happen if a connection is inserting a child using HTTP API and another instance is trying to query the document using the Java API?; does the NodeUpdate DLL block the database document and puts the server on hold until the whole insert operation ends? Is that controlled by the transaction?

- What would happen if two different App. servers (say, in a cluster) try to update the same document at the same time using the Java API (not the nodeUpdate)?

To me, it is very important to have node-level access to update or insert in an existing document. I think it is the basic required functionality from a DB. Hopefully SAG will provide this pretty soon as said in some postings.

  • Since you can go either way, what would happen if a connection is inserting a child using HTTP API and another instance is trying to query the document using the Java API?; does the NodeUpdate DLL block the database document and puts the server on hold until the whole insert operation ends? Is that controlled by the transaction?


    As I understand it - if the nodelevel update methods are a called in a tranaction context the node level update DLL uses that that transaction to lock that document during the update.

    If the methods are called in a transactionless context a transaction is initiated to preform the update and then committed and closed.

Are you using the Java DOM API as delivered with Tamino?

Microsoft have abandoned the idea of “replace mode” installation of the MSXML control. So when you install MSXML4 it does not replace an existing MSXML3. You have to explicitly use MSXML4 by instantiating “MSXML2.DOMDocument.4.0”

NodeLevelUpdate doesn’t do this, so unless MSXML3 is also installed, you will get the exception you reported. So I will change the FAQ to say that MSXML3 is required - thanks.

Nigel: Yes, I am using the Java DOM API that comes with Tamino 3.1.1.1 (docuverse)when I need to send something to the database, in my application I am using Xerces 2.0.

As far as I know this version has only been checked out with Docuverse DOM.

If you need a version of this API that supports DOM2 /SAX2 (in particular Xerces) and a cross DOM serialization I can supply one - but we don’t support it officially - though you can get help from this discussion group

Nigel: Thanks! yes, I am interested, that may improve performance since I wouldn’t have to do re-parsing. My email: Juan.F.Arjona@cso-aker.com.

Thanks again.