I have problems with cursors. We are developing a system where a paginated list is displayed, this implementation has been developed using Cursors. During the cursor life, a user can define a Schema in the same collection where the list vales were retrieved, but the definition process is waiting for cursor release.
I tried to create a Connection to Tamino and Create a Cursor without blocking any document, executing the followings Xmachine commands.
you are addressing the interoperability of transactional and locking settings, cursoring, and xquery vs. x-query. I tried to explain this in a webcast for Tamino v4.2. Because there are no changes from that version on, all the information there is still valid for Tamino v4.4. May be you want to have a look: http://training.software-ag.de/_webcasts/tamino/TaminoV4.2_Locking4_MGM.ppt.
The problem you experience is caused by the following:
In Tamino cursors can only exist in a transactional context. _sensitive=no has an effect on locking for xquery. With _sensitive=no the query processor completely evaluates the query at cursor open time. The query processor acquires document locks in the same way as it would do without cursoring. In your case with _lockMode=unprotected it does not acquire any document locks. [With _sensitive=vague xquery cursors require independent of the _lockMode settings at least shared locks.]
But, although you do not need locks on documents, Tamino nevertheless acquires locks on the collection and doctype level. These locks ensure that within a transaction your queries, updates, etc. have a consistent view at schema information, e.g. usage of server extensions, definition of elements or attributes that are used within a query etc. These collection and doctype locks are so-called “intention shared” locks which means that not the entire collection or doctype but some members (documents) are in use. These “intention shared” locks are incompatible with exclusive locks.
For schema processing the schema processor requires exclusive access to the entire collection, independent of which doctypes are affected by the schema change.
These two types of locks cause the waiting situation you describe.
From my rather limited point of view, without knowing anything about your application, I would recommend to check whether it is really necessary that the schema changes need to be done on the same collection where the cursored data resides. If yes, it could be a solution to use the optimized position()-xqueries which allow for efficient access to specified chunks of data.