Geert, Using a process similar to what Danny described, and you've already implemented, those (micro?)seconds shouldn't matter. As he mentioned, MarkLogic Server guarantees that for any two queries trying to update a given document the second query will see the results of the first query. We can use this to our advantage, but we need to make sure that we're seen as an update query by the server:
let $force-update-mode := xdmp:document-insert("/mutex-doc.xml", <foo />)
let $user := "user-the-first"
return
(: do lock checking and updating here :)
For this to be performant you'll have to create multiple mutex docs that in
some way correspond to the documents you wish to update. But all queries
that want to update a given document are going to have to block on the call
to xdmp:document-insert() until the current query, with the lock on the
mutex, has finished executing.
-fs
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Geert Josten
Sent: Tuesday, February 10, 2009 3:18 PM
To: General Mark Logic Developer Discussion
Subject: RE: [MarkLogic Dev General] Atomic and exclusive
lockondocuments(accross a cluster)
Hi Danny,
Thanks for your input.
Actually, we have similar logic, though we use the 'owner' property of locks
themselves. It is more or less like this:
Acquiring the lock:
if (not(document-locks($uri))) then
lock-acquire($uri, 'exclusive', 0, $owner, ())
else
error('already locked')
Performing update:
if (document-locks($uri)//lock:owner = $owner) then
do-update($uri)
Else
error('locked by someone else')
The issue is in acquiring the lock. There is time between the moment of
checking for locks and acquiring the actual lock. It is very small (perhaps
just a few CPU cycles), but time nontheless, which leaves room for other
threads or requests to make a same call to lock-acquire at 'the same' time.
Lock-acquire is atomic across a cluster, but since all lock-acquire calls
are executed by the same user, it never fails, not providing us the
exclusive lock we hoped to get.
Kind regards,
Geert
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Danny Sokolsky
> Sent: dinsdag 10 februari 2009 20:16
> To: General Mark Logic Developer Discussion
> Subject: RE: [MarkLogic Dev General] Atomic and exclusive
> lock ondocuments(accross a cluster)
>
> You can store your locks in a separate document (or in a
> property on the same document), and have your application
> logic only allow updates if the "user" (that is, from your
> app's perspective, since you are only using one MarkLogic
> user) is the one with the lock. The main difference between
> this and the lock-acquire approach is that your application
> must manage the locks.
>
> If you implement this correctly, it should solve the problem
> of the second update request seeing what happened from the
> first update request. Internally in MarkLogic Server,
> updates must get a write lock on a document before it can be
> updated. If someone else has the write lock, then another
> update request must wait for the lock to be released before
> it can proceed with its transaction.
>
> Imagine this scenario:
>
> /doc/mydoc.xml has the following property:
>
> <owner>user-a</owner>
>
> Your application code has a variable $user that is set to the
> current user. Before any updates can occur, your code has
> some logic like this:
>
> let $user := "user-a"
> return
> if ($user ne fn:data(
> xdmp:document-get-properties("/doc/mydoc.xml", fn:QName("",
> "owner"))) )
> then fn:error("NOUPDATE", "You cannot update because you are the wrong
> user")
> else "put update code here"
>
> I might be missing something, but it seems like this approach
> would work. Of course implementing a content management
> system is complicated, and you might find that managing the
> security in the application layer will quickly get very
> complex. For the simple case, however, it seems doable from
> my naive perspective.
>
> -Danny
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of
> Geert Josten
> Sent: Monday, February 09, 2009 11:52 PM
> To: General Mark Logic Developer Discussion
> Subject: RE: [MarkLogic Dev General] Atomic and exclusive
> lock ondocuments(accross a cluster)
>
> Hi Danny,
>
> Tjerk is my colleague. We already have something like that,
> using the owner field of locks themselves, as we needed locks
> over multi-transactions anyhow. But we need absolute 100
> percent guarantee that if two requests are challenging for an
> exclusive lock on the same document, only one can be
> acquired. Unfortunately, since we are using an application
> user, the xdmp:lock-acquire function never fails. And however
> small, there is time between checking for a lock and
> acquiring the lock itself, so leaving a tiny gap for two
> requests to get a lock on the same document.
>
> Moreover, I noticed that the first lock is being overwritten
> by the second, effectively extending the lock-period (which
> could be usefull).
> If the second request comes from some other user, and the
> first response is is a success, the evidence of the first
> request will get lost. We really would like to prevent this to happen.
>
> One workaround we thought of ourselves is to create temporary
> users (one for each lock) and use xdmp:eval to acquire the
> lock as that user. But that sounds like unnecessary overhead
> and is likely to be error prone (error handling, releasing
> locks and removing those temp users is tricky).
>
> Any suggestion at all would be welcome..
>
> Kind regards,
> Geert
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Danny
> > Sokolsky
> > Sent: maandag 9 februari 2009 20:07
> > To: General Mark Logic Developer Discussion
> > Subject: RE: [MarkLogic Dev General] Atomic and exclusive lock on
> > documents(accross a cluster)
> >
> > Hi Tjerk,
> >
> > One approach you can take is to store the current owner of the
> > document somewhere in the document, or in the document properties.
> > Then, in your application, you can have logic that only allows that
> > user to update the document. For example, if you had a
> property that
> > looked something like
> > this:
> >
> > <owner>user-a</owner>
> >
> > Then you might have some logic in your update module that
> checked that
> > the user was user-a before allowing him to update the document. Of
> > course it would be up to you to write that logic correctly.
> >
> > During the update in MarkLogic Server, the document is
> locked across
> > the cluster--that is a key part of the transaction semantics of
> > MarkLogic Server.
> >
> > -Danny
> >
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of Tjerk
> > Stroband
> > Sent: Monday, February 09, 2009 6:31 AM
> > To: [email protected]
> > Subject: [MarkLogic Dev General] Atomic and exclusive lock on
> > documents(accross a cluster)
> >
> > Hi all,
> >
> > During development of a particular application a number of
> > architectural design decisions have been made. One of these
> decisions
> > was to not used the internal ML user-database since that
> would require
> > the client application to do user-impersonation etc and require
> > complex synchronization procedures with the LDAP (which is used to
> > store all the users). Instead the application will use a single
> > application user-account to access ML.
> >
> > However, the application requires support for exclusively and
> > atomically (across the cluster) locking documents
> (regardless of the
> > user since only one user accesses ML) as part of a pessimistic
> > locking-scheme for use by an external workflow.
> > The logical way to achieve this would be to use the
> xdmp:lock-acquire
> > and xdmp:lock-release functions. However, these functions
> only lock a
> > document for a particular user.
> > Two consecutive calls to the xdmp:lock-acquire function
> using the same
> > user will not cause the second call to fail, regardless of the
> > description.
> > Instead they both succeed and the description will have that of the
> > last call.
> >
> > This poses a significant challenge as it seems it is
> impossible to get
> > an exclusive and atomic lock on a document when not using
> named users
> > in ML.
> >
> > Is our analysis correct or are we missing something?
> >
> > Best regards,
> >
> > Tjerk Stroband
> > Daidalos
> > The Netherlands
> >
> >
> >
> > T. I. Stroband
> > Senior consultant
> > GSM: +31 (0)6 22 52 44 45
> >
> >
> > Daidalos BV
> > Source of Innovation
> > Hoekeindsehof 1-4
> > 2665 JZ Bleiswijk
> > Tel.: +31 (0) 10 850 1200
> > Fax: +31 (0) 10 850 1199
> > http://www.daidalos.nl/
> > KvK 27164984
> > De informatie - verzonden in of met dit emailbericht - is afkomstig
> > van Daidalos BV en is uitsluitend bestemd voor de geadresseerde.
> > Indien u dit bericht onbedoeld hebt ontvangen, verzoeken
> wij u het te
> > verwijderen. Aan dit bericht kunnen geen rechten worden ontleend.
> >
> >
> >
> > _______________________________________________
> > General mailing list
> > [email protected]
> > http://xqzone.com/mailman/listinfo/general
> > _______________________________________________
> > General mailing list
> > [email protected]
> > http://xqzone.com/mailman/listinfo/general
> > _______________________________________________
> General mailing list
> [email protected]
> http://xqzone.com/mailman/listinfo/general
> _______________________________________________
> General mailing list
> [email protected]
> http://xqzone.com/mailman/listinfo/general
> _______________________________________________
General mailing list
[email protected]
http://xqzone.com/mailman/listinfo/general
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ General mailing list [email protected] http://xqzone.com/mailman/listinfo/general
