[XQZone General] Guaranteed unique?

[Ian Small]

One quick note to follow up on this posting stream.

When you use eval() etc. to evaluate an update request from an original
request that is performing an update, it is possible that the two update
requests will deadlock with each other.  In this situation, it is
impossible for the server to resolve the deadlock, as the simultaneous
invocation of the two update requests is determined by the XQuery code
provided.  Unresolvable deadlocks in the server lead to undesirable
server behavior.

In order to eliminate this undesirable server behavior, we expect that
in a future minor release the server will no longer allow you to perform
updates in a request launched via eval(), eval-in(), invoke(), or
invoke-in() when that update request is launched from another request
performing updates.  Launching read-only queries from update requests,
or update requests from read-only queries, will continue to be
supported.

This problematic behavior was recently identified by us in the course of
ongoing testing and evaluation.  After significant investigation, we
have determined that this admittedly large-scale change in behavior is
the most viable solution, and that the negative impact of unresolvable
server deadlocks is sufficiently large to warrant the change.

Consequently, our most recent maintenance release, 3.0-4, contains to
support this code structure (thereby continuing to allow the potential
for this type of unresolvable system deadlock) in order to maintain
compatibility with previous 3.0 releases.  However, it simultaneously
logs a warning message into the system log indicating the potential for
problems.  The warning message indicates that this query structure will
not be supported in a future minor release.  This bug is filed as a
"known bug" in 3.0.

For this reason, while the strategy you are outlining below will work in
current and previous releases (I suspect that you may be running an
older release of the server), you should be aware of:
(a) the potential for server deadlocks if you reference the same
documents in the evaler request and the evalee request, and both
requests can perform updates
(b) the long-term dead-end of this approach.

All that being said, as Jason has said, we have logged your request for
the "autoincrement" functionality.

ian

-----Original Message-----
From: general-bounces at xqzone.marklogic.com
[mailto:general-bounces at xqzone.marklogic.com] On Behalf Of Jason Hunter
Sent: Monday, November 28, 2005 9:52 AM
To: General XQZone Discussion
Subject: Re: [XQZone General] Guaranteed unique?

Stewart, Joel (LNG-DAY) wrote:

> I have been wondering how to accomplish this when needing to call it a

> number of times from within an xquery function, e.g.:
 >
 > ...
 >
> One idea is to use eval-in.  I have been wondering if using that to 
> put your ids in another database would work around the above issue.
> Apparently it does.  

Yes, that's a viable approach to executing and committing an update in
the middle of a larger query.

> So, running this will work.  The hard part will be putting error 
> handling and retry logic in the function calling it - if it so happens

> two threads get on that node at the same time and cause conflicting 
> updates.

Actually that won't cause conflicting updates; that will just cause the
second thread to block until the first update is finished.  A
conflicting update happens only at the end of a single query when the
multiple changes requested within that query conflict with each other. 
For example: adding a node to a parent, then deleting the parent.  You
presently can't do that because the two changes within the same query
step on each other's toes.

So your solution above is more robust than you thought.  :)

 > But I think this goes a long way toward what is needed to be
> implemented natively in marklogic - some "autoincrement" function that

> is not bound to the same rollback, and is atomic such that you will 
> not get the conflicting updates exception.

I'll make sure that's added to the requested features list.

-jh-

_______________________________________________
General mailing list
General at xqzone.marklogic.com
http://xqzone.com/mailman/listinfo/general