Which situation is that? Thread race? Is
there a potential for data corruption and/or
server crash? How are non-atomic values stored?
I want to make a cache, which requires red/write
access from many requests, possibly concurrently.
Can I do that? Will it periodically explode in a
shower of sparks?
On Feb 29, 2012, at 5:43 PM, Micah Dubinko wrote:
> Ron,
>
> The plugin implementation uses a map stored in a server-field. Accessor
> functions that return one of these maps explicitly make a copy of it in order
> to prevent the situation you described. -m
>
>
>
> On Feb 29, 2012, at 9:28 AM, Ron Hitchens wrote:
>
>>
>> I have a question about how server fields work that
>> I'm hoping someone in Engineering can shed some light
>> on.
>>
>> The docs for xdmp:{get,set}-server-field are pretty
>> clear. Much like a map, you can set or get a value for
>> a given key:
>>
>> xdmp:set-server-field("foo", "bar")
>> => "bar"
>>
>> xdmp:get-server-field("foo")
>> => "bar"
>>
>> Handy. But the value (second arg of set, return
>> value of both get and set) is typed as item()*. So
>> what happens if you set a value that is not an atomic
>> value, such as a map object?
>>
>> let $my-map := map:map()
>> let $_ := map:put ($my-map, "my-key", "first-value")
>> return xdmp:set-server-field("global-map", $my-map)
>> => map:map
>>
>> This request then ends and at some time in the future
>> another one runs and does:
>>
>> let $my-map := xdmp:get-server-field("global-map")
>> return map:get ($my-map, "my-key')
>> => "first-value"
>>
>> Later it does: map:put ($my-map, "my-key", "second-value")
>>
>> A third request runs later and sees:
>>
>> let $my-map := xdmp:get-server-field("global-map")
>> return map:get ($my-map, "my-key')
>> => "second-value"
>>
>> I've written some code like this and it seems to work this
>> way. Changes to a map fetched from a server variable do
>> appear to be persistent, consistent with the server variable
>> storing a reference to the map rather than a copy.
>>
>> As I thought about this, it made me wonder if this is
>> really the case. If a stashed map can be fetched and updated
>> by any request, isn't that a thread race? Where does the "real"
>> map live, once the request that instantiated it has terminated?
>> If non-atomic values can be stored in a server variable, how
>> is the graph of references managed if the value is to live on
>> after the instantiating request terminates?
>>
>> So how do server variables work under the covers? Is there
>> any special action being taken to preserve access-by-reference
>> behavior, or is it intended to store copies of simple values
>> only (and it just hasn't blown up for me yet)?
>>
>> Thanks.
>>
>> ---
>> Ron Hitchens {mailto:[email protected]} Ronsoft Technologies
>> +44 7879 358 212 (voice) http://www.ronsoft.com
>> +1 707 924 3878 (fax) Bit Twiddling At Its Finest
>> "No amount of belief establishes any fact." -Unknown
>>
>>
>>
>>
>> _______________________________________________
>> General mailing list
>> [email protected]
>> http://developer.marklogic.com/mailman/listinfo/general
>
> _______________________________________________
> General mailing list
> [email protected]
> http://developer.marklogic.com/mailman/listinfo/general
---
Ron Hitchens {mailto:[email protected]} Ronsoft Technologies
+44 7879 358 212 (voice) http://www.ronsoft.com
+1 707 924 3878 (fax) Bit Twiddling At Its Finest
"No amount of belief establishes any fact." -Unknown
_______________________________________________
General mailing list
[email protected]
http://developer.marklogic.com/mailman/listinfo/general
