Thank you Charles!
Tim From: [email protected] [mailto:[email protected]] On Behalf Of Charles Greer Sent: Monday, February 25, 2013 3:21 PM To: [email protected] Subject: Re: [MarkLogic Dev General] Asyncronous Status Updates Hi Tim, It's hard to puzzle together what you're trying to do, but here's what I was thinking: .. start transaction . document update . status doc inserted (new one for every update) .. end transaction now the new status doc is available, and the document is updated in one transaction. To other processes the status doc would be invisible. To get the latest status at any time, have some value with a timestamp on it, and use a range index query on that element to always get the maximum value. cts:search(/statuses, cts:element-value-query(xs:QName("timestamp"), cts:element-values(xs:QName("timestamp"), 1, ("descending")))) It looks like this handles the 'get latest record' requirement. I guess you have state you need in that status document that wouldn't support an insert-only approach. Charles On 02/25/2013 10:39 AM, Tim wrote: Hi Charles, I actually do this and keep them is a separate directory URI, but I keep the most current status available at all times while keeping a copy of each new status record for historical purposes. And they are small as you recommend. If I didn't keep a current copy of the status, I'm not sure how I would be able to avoid contention for the latest record which I would still be required to access. It would avoid locking, but I wouldn't be guaranteed to get the latest copy of the status nor to keep it current when updating it. Admittedly I haven't looked into how to choose the transaction isolation. I suppose best and customary practices are dependent on system requirements, but can you provide an example of the implementation you describe? Thanks! Tim From: [email protected] [mailto:[email protected]] On Behalf Of Charles Greer Sent: Monday, February 25, 2013 12:40 PM To: [email protected] Subject: Re: [MarkLogic Dev General] Asyncronous Status Updates Hi Tim, To follow on what Damon's suggesting-- you might also want to make the status documents very small, such that each update is really an insert. We've seen this approach a lot; accessors will aggregate the status documents for examination, but each recorded fact is its own document. "A document is a row, not a table." No update locking contention in this scenario, and you can choose the transaction isolation or synchronous/asynch to address other requirements in the system. Partitioning these status documents from the rest of the database, by collection or directory, would help organize them.` Charles _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general -- Charles Greer Senior Engineer MarkLogic Corporation [email protected] Phone: +1 707 408 3277 www.marklogic.com
_______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
