Locking and long-running update operations
Quoted text · Charles Duffy · 10 lines
On 04/03/2012 06:43 PM, Charles Duffy wrote: > I have a set of expensive cached data which requires about ~20 minutes > to refresh/recalculate. However -- while this recalculation is running > (via a single XQUF operation), read queries against the same database > are unable to operate. > > My expectation is that the old, pre-update data will remain continually > available until the update commits. If this expectation is incorrect, > what is the suggested mechanism for running such expensive updates > without impacting availability?
I think snapshot isolation is planned for a future release.
kind regards, Johannes
I have a set of expensive cached data which requires about ~20 minutes to refresh/recalculate. However -- while this recalculation is running (via a single XQUF operation), read queries against the same database are unable to operate.
My expectation is that the old, pre-update data will remain continually available until the update commits. If this expectation is incorrect, what is the suggested mechanism for running such expensive updates without impacting availability?
Quoted text · Charles Duffy · 12 lines
On 04/03/2012 12:10 PM, Johannes.Lichtenberger wrote: > On 04/03/2012 06:43 PM, Charles Duffy wrote: >> I have a set of expensive cached data which requires about ~20 minutes >> to refresh/recalculate. However -- while this recalculation is running >> (via a single XQUF operation), read queries against the same database >> are unable to operate. >> >> My expectation is that the old, pre-update data will remain continually >> available until the update commits. If this expectation is incorrect, >> what is the suggested mechanism for running such expensive updates >> without impacting availability? > I think snapshot isolation is planned for a future release.
I see.
Are there widely used practices to workaround lack of support presently (such as staging pending updates in a different database and then doing copy operations)?
The ability to execute an update list immediately (thus breaking down a large operation into smaller, shorter transactions) might also be helpful. I suppose that worst-case, this could be done by having XQuery code call the REST API via the HTTP module to run atomic, updating subqueries.
Written for BaseX 7.2. BaseX may have changed since: please check the current documentation.