New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi-statement Transactions with RXQ #11

Open
cfoster opened this Issue Apr 25, 2013 · 33 comments

Comments

Projects
None yet
5 participants
@cfoster
Contributor

cfoster commented Apr 25, 2013

Multi-statement Transactions with RXQ

10,000 foot view

Need to perform multi-statement transaction, over a HTTP interface provided by RXQ.

The following table, describes the basic approach:

Path Method Action
/transaction/start POST Starts a multi-statement tx in "update" mode
/transaction/commit POST Commits a multi-statement transaction
/transaction/rollback POST rolls back a multi-statement transaction
/*** PUT inserts a document
/*** GET retrieves a document

In this instance, the client and the server keep "state" by using the SessionID cookie (which MarkLogic issues).

Expected Behaviour

  1. Client issues /transaction/start. Server responds with SessionID cookie.
  2. Client issues subsequent query/update requests, with the SessionID cookie.
  3. Client issues /transaction/commit or /transaction/rollback, with SessionID cookie.

Also, most requests which go through the RXQ framework will be read only searches, it is important that these requests are ran in the context of a "query" and not an update transaction. In order to ensure the static analyser does not stumble into the trap of turning all requests into update transactions based on finding potential "update" code somewhere else within the RXQ resource module, all update code is, for this example, performed in an evil xdmp:eval.

Isolated Example - RXQ Resource Module

The following code is an example RXQ Module which attempts to achieve this behaviour.

xquery version "1.0-ml";

module namespace tx = "https://github.com/xquery/rxq/issues/11";

import module namespace rxq="http://exquery.org/ns/restxq"
  at "/util/lib/rxq.xqy";

declare variable $same-statement-update-options :=
  <options xmlns='xdmp:eval'>
    <isolation>same-statement</isolation>
    <transaction-mode>update</transaction-mode>
  </options>;

(: ----------------------- Transaction specific code ----------------------- :)
declare
  %rxq:POST
  %rxq:path('/transaction/start')
function tx:start()
{ (: the evil eval - purely for illustrating this isolated example :)
  xdmp:eval('
    xquery version "1.0-ml";
    declare option xdmp:transaction-mode "update";
    xdmp:log("transaction started")',
    (),
    $same-statement-update-options
  )
};

declare
  %rxq:POST
  %rxq:path('/transaction/commit')
function tx:commit()
{
  xdmp:commit()
};

declare
  %rxq:POST
  %rxq:path('/transaction/rollback')
function tx:rollback()
{
  xdmp:rollback()
};
(: ------------------------------------------------------------------------- :)

(: ------------------------------ GET and PUT ------------------------------ :)
declare
  %rxq:GET
  %rxq:path('/(.*)')
  %rxq:produces('text/xml')
function tx:get($var1)
{
  if(fn:doc-available("/" || $var1)) then
    fn:doc("/" || $var1)
  else (
    xdmp:set-response-code(404, "Not Found"),
    document { <not-found /> } (: to satisfy %rxq:produces :)
  )
};

declare
  %rxq:PUT
  %rxq:path('/(.*)')
  %rxq:produces('text/xml')
function tx:put($var1)
{
  (: the evil eval - purely for illustrating this isolated example :)

  xdmp:eval(
    'xquery version "1.0-ml";
    declare variable $uri as xs:string external;
    declare variable $value as document-node(element()) external;
    xdmp:document-insert($uri, $value)',
    (
      xs:QName("uri"), "/" || $var1,
      xs:QName("value"), xdmp:get-request-body("xml")
    ),
    tx:insert-eval-options()
  ),

  document { <OK /> }
};
(: ------------------------------------------------------------------------- :)

(:~
 : Called by tx:put($var1)
 :)
declare function tx:insert-eval-options() as element()
{
  (:
    If the current request is not in an "update transaction",
    i.e. this is an "adhoc" insert that is not part of any multi-statement
    transaction, MarkLogic thinks (perhaps from XQuery
    static analysis), that the current transaction is a "query".

    I have found the only way to stop MarkLogic producing a
    XDMP-UPDATEFUNCTIONFROMQUERY exception is to insert an adhoc document via a
    different transaction, which is OK.

    However, if the current request is part of an "update" transaction,
    then we definitely want updates made in this request to be performed
    within the context of this transaction, so I've used
    "same-statement" instead of "different-transaction".
  :)
  <options xmlns='xdmp:eval'>
    <isolation>
    {
      switch(xdmp:get-transaction-mode())
        case "auto" return "different-transaction"
        case "query" return "different-transaction"
        case "update" return "same-statement"
        default return "unknown"
    }</isolation>
  </options>
};

Where this works

This works well, when performing one operation and then choosing to commit or rollback, e.g.

  1. HTTP Request to: start a transaction
  2. HTTP Request to: insert a document via a PUT
  3. HTTP Request to: commit or rollback the transaction.

Where this doesn't work (and the issue)

Once the client issues more than one operation during the context of a transaction, the "update transaction" disappears from MarkLogic.

For instance:

  1. HTTP Request to: start a transaction (update tx)
  2. HTTP Request to: perform a PUT. (works fine, tx exists in MarkLogic)
  3. HTTP Request to: perform a PUT. (works fine, tx exists in MarkLogic)
  4. HTTP Request to: perform a PUT. (tx has disappeared from MarkLogic)
  5. ErrorLog.txt: XDMP-NOTXN: No transaction with identifier 13797797255741043997

NOTE: MarkLogic appears to have committed the update transaction, after finishing the third request. Which must be why the transaction has now disappeared.

My take on the problem

Please excuse my assumptions here, I may be completely wrong.

On starting a transaction with the example RXQ module, this runs a new query with the xdmp:transaction-mode "update" option, albeit in the same-statement, this delays the start of the actual update transaction until the next HTTP request which then must start a multi-statement transaction. The second HTTP request then does the actual starting of the update transaction and does its thing - but also, importantly doesn't commit the transaction.

On the third HTTP request, unless the request specifically calls xdmp:commit() or xdmp:rollback() the entire update transaction is automatically commited by MarkLogic at the end of its execution.

This is different to behaviour when executing Main Modules directly on a HTTP App Server.

Consider the following Main Module, sitting on a HTTP App Server:

xquery version "1.0-ml";
declare option xdmp:transaction-mode "update";
()

Executing this, immediately starts the update transaction, it's visible after running.

All subsequent HTTP requests (with the cookie) operate in "update" mode and do not commit/rollback until a statement finally invokes a xdmp:commit() or xdmp:rollback().

For RXQ (and the example given), the third request also appears to run in "update" mode, but strangely, automatically commits at the end of it's execution.

BASH / CURL commands to save you time

Create empty file

touch empty

Create basic XML file

echo "<e>Hello World</e>" > test.xml

Start a transaction

curl -X POST -i -d @empty -u "admin:admin" "http://localhost:8012/transaction/start"

PUT a document (With a SessionID Cookie)

curl -i -X PUT -u "admin:admin" -H "Content-Type:text/xml" \
-H "Cookie: SessionID=4a48a573c6c0bda5; path=/" -u "admin:admin" \
-d @test.xml "http://localhost:8012/test.xml"

GET a document (With a SessionID Cookie)

curl -X GET -i -H "Cookie: SessionID=4a48a573c6c0bda5; path=/" \
-u "admin:admin" "http://localhost:8012/test.xml"

Commit a transaction (With a SessionID Cookie)

curl -X POST -i -d @empty -u "admin:admin" \
-H "Cookie: SessionID=4a48a573c6c0bda5; path=/" "http://localhost:8012/transaction/commit"

Rollback a transaction (With a SessionID Cookie)

curl -X POST -i -d @empty -u "admin:admin" \
-H "Cookie: SessionID=4a48a573c6c0bda5; path=/" "http://localhost:8012/transaction/rollback"
@cfoster

This comment has been minimized.

Contributor

cfoster commented Apr 25, 2013

Hi Jim,

I may be going about this completely the wrong way?

If it needs to be redesigned to work in a different manner, perhaps using the undocumented XA / transaction functions found in John's /Modules/MarkLogic/xa.xqy module, I'd be fine with that.

Any help you could give would be most appreciated.

@xquery

This comment has been minimized.

Owner

xquery commented Apr 25, 2013

my initial response is 'do you have this working' outside of RXQ, as a standalone module to test your expectations? As previously mentioned, RXQ does not specific handling of transactions, so either there is a gap in expectation or some kind of deficiency in underlying ml impl that only shows up with xquery 3.0 features.

have you tried inserting

declare option xdmp:transaction-mode "update";

into the rxq library module ?

will review in deeper detail this wonderfully detailed bug report, thx!

@jpcs

This comment has been minimized.

jpcs commented Apr 25, 2013

Use xdmp:set-transaction-mode() in start(). Also set the transaction mode back to auto when committing or rolling back.

App servers handle errors during multi-statement txns differently to XDBC connections - I believe the app server will just rollback the transaction immediately.

@xquery

This comment has been minimized.

Owner

xquery commented Apr 25, 2013

also to clarify my advice, have you got this working in a standalone xquery module w/o any rewriter involved

@cfoster

This comment has been minimized.

Contributor

cfoster commented Apr 25, 2013

Jim

Moving declare option xdmp:transaction-mode "update";

It's only possible to put declare option xdmp:transaction-mode "update"; in a Main Module and not a Library Module.

Putting the option in the rxq-rewriter.xqy Main Module causes:

  1. An update transaction to start and be visible immediately, as the Main Module I described in my ticket does, the transaction is then in a state similar to that of 'request 2' in my ticket with regards to what happens next.
  2. The next request (routed through) rxq-rewriter.xqy performs it's operation, and then like request 3 in my ticket, causes the transaction to auto-commit instead of staying as an "update" transaction and remaining open.
  3. Even if this approach worked, it would not be great, because each request routed through RXQ would run in "update" mode, putting "read locks" on all fragments returned from searches and lookups. I would have to break into separate transactions to run a query with a non-blocking timestamp. Which may get messy.

Working in a stand-alone Main Module

Yes. this works outside of RXQ, in stand-alone Main Modules.

Consider the following Main Module, sitting on a HTTP App Server, /start-transaction.xqy:

xquery version "1.0-ml";
declare option xdmp:transaction-mode "update";
()

Executing this, starts an update transaction, which is immediately visible, unlike start() in RXQ.

Another Main Module, sitting on the same HTTP App Server, /doc.xqy:

xdmp:get-transaction-mode(),
fn:doc()[1]

When executed, passing the SessionId Cookie back to the server, always results in:

update
<?xml version="1.0" encoding="UTF-8"?>
<document-content />

The update transaction is finally committed, once the Main Module /commit.xqy on the same HTTP App Server is executed (of course, with the same SessionID):

xdmp:commit()

John

I tried xdmp:set-transaction-mode(), I tried it everywhere in fact, in all manner of permutations, for hours - got stressed, then gave up and put all of my attention into writing a clear support ticket.

Using xdmp:set-transaction-mode("update") in start() causes the same result as executing a query in the same statement with the update option.

@xquery

This comment has been minimized.

Owner

xquery commented Apr 25, 2013

yes, thx for reading my mind (re rewriter).

as a interim backup you could code this function outside of rewriter, eg as standalone and invoke them

I am going to need more time to dig into this ... realistically that wont happen till the weekend (in terms of a large block of time). Thanks once again for the level of detail, it will help.

@cfoster

This comment has been minimized.

Contributor

cfoster commented Apr 25, 2013

Just a thought.

Did Corona support multi-statement transactions?, I am pretty sure that the RESTful API for MarkLogic supports multi-statement transactions.
Both apps are essentially rewriter engines like RXQ. Before the weekend's here, perhaps you could ask some fellow MarkLogicians if they faced any issues like this? and if so how they resolved them?

@jpcs

This comment has been minimized.

jpcs commented Apr 25, 2013

Try turning on trace flags "Transaction Create" and "Transaction Complete", and log the session ID values that are being sent and returned. Also look at the "TxnMode" and "TxnID" cookies returned from the server (you don't need to send these back again though - they are informative only).

@xquery

This comment has been minimized.

Owner

xquery commented Apr 25, 2013

i've already had a sniff about, also John is the worlds expert on ML multi statement transactions ...

I am unsure if Corona supported multi statement transactions

@xquery

This comment has been minimized.

Owner

xquery commented Apr 26, 2013

fyi - I will be investigating this in full come sat morning ... so far I still think its not an RXQ issue eg. its related to rewriter ...potentially you may have to raise a support ticket with ML, but will say so if required

@cfoster

This comment has been minimized.

Contributor

cfoster commented Apr 26, 2013

Thanks very much Jim!

@xquery

This comment has been minimized.

Owner

xquery commented Apr 27, 2013

I got the following working ... basically the theory is you would use xdmp:invoke to call a standalone module ... its not as elegant as I would hope for, but works.

so your trans module lib (with RESTXQ annotations) would look like

xquery version "1.0-ml";

module namespace tx = "https://github.com/xquery/rxq/issues/11";

declare namespace rxq="http://exquery.org/ns/restxq";


(: ----------------------- Transaction specific code ----------------------- :)
declare
  %rxq:POST
  %rxq:path('/transaction/start')
function tx:start()
{
    xdmp:invoke("/test.xqy", 
        (xs:QName("action"), "start"), 
       <options xmlns='xdmp:eval'>
    <isolation>same-statement</isolation>
    <transaction-mode>update</transaction-mode>
  </options>)
};

declare
  %rxq:POST
  %rxq:path('/transaction/commit')
function tx:commit()
{

    xdmp:invoke("/test.xqy", 
        (xs:QName("action"), "commit"), 
       <options xmlns='xdmp:eval'>
    <isolation>same-statement</isolation>
    <transaction-mode>update</transaction-mode>
  </options>)

};

declare
  %rxq:POST
  %rxq:path('/transaction/rollback')
function tx:rollback()
{
    xdmp:invoke("/test.xqy", 
        (xs:QName("action"), "rollback"), 
       <options xmlns='xdmp:eval'>
    <isolation>same-statement</isolation>
    <transaction-mode>update</transaction-mode>
  </options>)

};

(: ------------------------------------------------------------------------- :)

(: ------------------------------ GET and PUT ------------------------------ :)
declare
  %rxq:GET
  %rxq:path('/(.*)')
  %rxq:produces('text/xml')
function tx:get($var1)
{
  if(fn:doc-available("/" || $var1)) then
    fn:doc("/" || $var1)
  else (
    xdmp:set-response-code(404, "Not Found"),
    document { <not-found /> } (: to satisfy %rxq:produces :)
  )
};

declare
  %rxq:PUT
  %rxq:path('/(.*)')
  %rxq:produces('text/xml')
function tx:put($var1)
{
     xdmp:invoke("/test.xqy", 
        (xs:QName("action"), "put", xs:QName("uri"), "/" || $var1, xs:QName("value"), xdmp:get-request-body("xml")), 
       <options xmlns='xdmp:eval'>
    <isolation>same-statement</isolation>
    <transaction-mode>update</transaction-mode>
  </options>)
};

then the test.xqy module (with the declare option xdmp:transaction-mode "update";) does the work

xquery version "1.0-ml";

declare variable $action external;
declare variable $uri external;
declare variable $value external;

     declare option xdmp:transaction-mode "update";

(: ------------------------------------------------------------------------- :)
declare function local:start()
{(
   xdmp:eval(
    'xquery version "1.0-ml";
      declare option xdmp:transaction-mode "update";            
      (xdmp:log(xdmp:transaction()))

    ',
    (),
    <options xmlns='xdmp:eval'>
    <isolation>same-statement</isolation>
    <transaction-mode>update</transaction-mode>
  </options>)          
 )       
};
(: ------------------------------------------------------------------------- :)
declare function local:commit()
{
(    
        xdmp:eval(
            'xquery version "1.0-ml";
            declare option xdmp:transaction-mode "update";
            xdmp:commit()
            ',
            (),
            <options xmlns='xdmp:eval'>
            <isolation>same-statement</isolation>
            <transaction-mode>update</transaction-mode>
            </options>)  
)        
};
(: ------------------------------------------------------------------------- :)
declare function local:rollback()
{
    xdmp:eval(
        'xquery version "1.0-ml";
        declare option xdmp:transaction-mode "update";
        xdmp:rollback()
        ',
        (),
        <options xmlns='xdmp:eval'>
        <isolation>same-statement</isolation>
        <transaction-mode>update</transaction-mode>
        </options>)     
};
(: ------------------------------------------------------------------------- :)
declare function local:get($uri)
{

  if(fn:doc-available($uri)) then
    fn:doc($uri)
  else (
    xdmp:set-response-code(404, "Not Found"),
    document { <not-found /> }
  )
};
(: ------------------------------------------------------------------------- :)
declare function local:put($uri, $value)
{
     xdmp:document-insert($uri, $value) 
};
(: ------------------------------------------------------------------------- :)

switch($action)
case "start" return local:start()
case "put" return local:put($uri,$value)
case "get" return local:get($uri)
case "commit" return local:commit()
case "rollback" return local:rollback()
default return ()

and you will need to add to rxq.xqy

declare option xdmp:update "true";

(near line 60)

some thoughts;

  • I maybe able to refactor rxq to do this in a more elegant fashion
  • you might be able to simplify test.xqy
  • your original cURL should work against this

hth, J

@ghost ghost assigned xquery Apr 27, 2013

@xquery

This comment has been minimized.

Owner

xquery commented Apr 30, 2013

closing this bug, and will note that 6.0.3 and higher is recc version of ML to run with RXQ

@xquery xquery closed this Apr 30, 2013

@xquery

This comment has been minimized.

Owner

xquery commented Jun 18, 2013

reopening this on request

@xquery xquery reopened this Jun 18, 2013

@cfoster

This comment has been minimized.

Contributor

cfoster commented Aug 16, 2013

Hi Jim,

I know you are very, very busy.

But I was just wondering if there had been any movement on this issue?

Regards,

Charles

@Chunyu01

This comment has been minimized.

Chunyu01 commented Nov 27, 2013

Hello Jim,
Would you be able to have a look at this issue recently?
We (TSO) are using rxq for our one of projects.
We appreciate if you have any progress with it.
Thanks,
Chunyu

@xquery

This comment has been minimized.

Owner

xquery commented Nov 28, 2013

the most common faq is interaction with eval for transactions

https://docs.marklogic.com/guide/app-dev/transactions#id_39749

as previously mentioned, depending on your situation you may have to amend things to work for your environment (which I have no view on).

Another thing that trips people up time and time again with tx over the web is that they program behavior on a single instance node and then deploy to a cluster and don't understand. Do you have some kind of load balancer in operation.

My suggestion is to raise a support issue (with MarkLogic) if transactions are not working in your environment as you would expect (as I outlined my example).

apart from the example I made a long time ago, I am unsure how I can help.

@xquery

This comment has been minimized.

Owner

xquery commented Jan 1, 2014

have not heard back on this ... if you are at XML Prague, be happy to take a personal look at things

@Chunyu01

This comment has been minimized.

Chunyu01 commented Jan 2, 2014

Hi James,

Thanks for asking.

Unfortunately, we have not got this issue resolved still. I would like to go to XML Prague, but there is very little chance that my company will let me go.

Regards,Chunyu

From: James Fuller [mailto:notifications@github.com]
Sent: 01 January 2014 15:32
To: xquery/rxq
Cc: Wilson, Chunyu
Subject: Re: [rxq] Multi-statement Transactions with RXQ (#11)

have not heard back on this ... if you are at XML Prague, be happy to take a personal look at things


Reply to this email directly or view it on GitHub #11 (comment) . https://github.com/notifications/beacon/4737766__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcwNDEyMzExNCwiZGF0YSI6eyJpZCI6MTAxOTMyMjF9fQ==--28f81bd8fe33fd6683769a389d5446a9a08c4ac8.gif


This e-mail has been scanned for all viruses by Claranet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.claranet.co.uk



This email is confidential and may also be privileged and/or proprietary to The Stationery Office Limited. It may be read, copied and used only by the intended recipient(s). Any unauthorised use of this email is strictly prohibited. If you have received this email in error please contact us immediately and delete it and any copies you have made. Thank you for your cooperation.
The Stationery Office Limited is registered in England under Company No. 3049649 at 1-5 Poland Street, London, W1F 8PR


@xquery

This comment has been minimized.

Owner

xquery commented Jan 2, 2014

Hello Chunyu,

Perhaps we can restart and if you provide me with a minimal example, I can convert it for you ?

J

@cfoster

This comment has been minimized.

Contributor

cfoster commented Jan 2, 2014

Hi Jim,

I'll be at Prague, but am now working on other things (not at TSO anymore).

The Tx problem may have been resolved with ML 7. It may have been something to do with the ML/REST library RXQ uses. But last time I checked on ML 6 anyway, there was certainly a problem with RXQ and multi-http request transactions despite multi-http request transactions working fine going direct to a module as well as via a URL rewriter. It was just RXQ that had the issue.

The original post is a concise and cut down example, if you have enough time to follow it through (and if the bug is still there with RXQ + ML 7) then you'll see and realise straight away something is amiss.

Looking forward to seeing you in Prague!

Charles

@xquery

This comment has been minimized.

Owner

xquery commented Jan 3, 2014

Hello Charles,

I answered your example 8 mths ago ... with demonstration code ...I get the feeling we are talking cross purposes here or maybe you want things just to run as you wrote your code example. This could be done though would change basic execution profile of RXQ ... RXQ does nothing special with transactions. We can discuss further at XML Prague ... looking forward to meeting up.

@cfoster

This comment has been minimized.

Contributor

cfoster commented Jan 3, 2014

Hi Jim

The demonstration code you gave, also shows the same bug which appears in the code I gave. Your code, like my code, doesn't allow multi-statement transactions, it allows for one single operation to be completed, which can then be committed or rolled back. If I remember correctly, trying to perform another operation within the context of the same transaction, but new HTTP request, commits everything.

I am aware RXQ does nothing special with transactions at all, I tried to investigate this and fix this issue myself but couldn't find it. Multi-statement (i.e. 2 or more) operations within the context of a single transaction do not work when using RXQ, where they DO however, work perfectly fine when going directly to an invokable module, or a URL re-writer.

@xquery

This comment has been minimized.

Owner

xquery commented Jan 3, 2014

ah right (prob too much time elapsing for me to remember) ... my code works on my platform for 6.03 and 7.0 so now we look for the delta ... if you could so kind as to supply me (possibly again) with the platform this was running on I think we are narrowing things down.

@Chunyu01

This comment has been minimized.

Chunyu01 commented Jan 3, 2014

HI James,

TSO, we are using Marklogic 6.0-4 version.

Chunyu


This email is confidential and may also be privileged and/or proprietary to The Stationery Office Limited. It may be read, copied and used only by the intended recipient(s). Any unauthorised use of this email is strictly prohibited. If you have received this email in error please contact us immediately and delete it and any copies you have made. Thank you for your cooperation.
The Stationery Office Limited is registered in England under Company No. 3049649 at 1-5 Poland Street, London, W1F 8PR


@xquery

This comment has been minimized.

Owner

xquery commented Jan 3, 2014

what platform ?

@cfoster

This comment has been minimized.

Contributor

cfoster commented Jan 3, 2014

TSO use Windows, but the problem was occurring on my Mac also.

The bug may have been some-how resolved already. To know for sure, you need to check with 2 or more operations within the context of the same transaction.

E.g. Something like:

  1. Start a transaction (1 single HTTP request).
  2. Perform an insert doc1.xml (1 single HTTP request).
  3. Perform an Insert doc2.xml (1 single HTTP request).
  4. Perhaps check to see two previous documents exist within the current transaction (1 single HTTP request).
  5. Rollback (1 single HTTP request).
  6. Check to see BOTH documents have disappeared.

I think TSO would probably accept any code that would work, they might even be persuaded to upgrade to ML 7 if that's what fixes the issue.

@Chunyu01

This comment has been minimized.

Chunyu01 commented Jan 3, 2014

I am not sure TSO will upgrade to M 7 just for this issue.
It will be great if this issue can be resolved for the present ML version we are using.
Thanks.

@xquery

This comment has been minimized.

Owner

xquery commented Jan 3, 2014

can you confirm exact platform being used ? Windows exact version in what configuration.

If you are having specific issues you can always raise a support request with MarkLogic (if you have support contract) or raise a specific question on MarkLogic mailing lists.

RXQ is just an open source software using core MarkLogic capabilities.

I can investigate further (esp if this is a bug, but I still doubt this), but can't make any promises. If I have the time I will try and craft yet another example. Please don't expect an instant response but I will try with the limited time I have.

@Chunyu01

This comment has been minimized.

Chunyu01 commented Jan 3, 2014

Server: Windows 2008 R2
MarkLogic version 6.0-4

Please let me know if you need more information.
Thanks.

@cfoster

This comment has been minimized.

Contributor

cfoster commented Jan 23, 2016

Hi Jim, As you're rewriting RXQ, please ensure to keep this issue in mind and is working with 2+ statements per update transaction.

@xquery

This comment has been minimized.

Owner

xquery commented Jan 23, 2016

thx for the reminder, on my list

@Fancellu2

This comment has been minimized.

Fancellu2 commented Oct 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment