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
