|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v4 3/4] xenstore: rework of transaction handling
On 31/03/17 13:00, Wei Liu wrote:
> On Thu, Mar 30, 2017 at 06:41:11PM +0200, Juergen Gross wrote:
> [...]
>>>
>>>> node->generation = generation++;
>>>> - return;
>>>> + if (conn && !conn->transaction)
>>>> + wrl_apply_debit_direct(conn);
>>>> + }
>>>> +
>>>> + if (!conn || !conn->transaction) {
>>>> + if (key)
>>>> + set_tdb_key(node->name, key);
>>>> + return 0;
>>>> }
>>>>
>>>> trans = conn->transaction;
>>>>
>>>> - node->generation = generation + trans->trans_gen++;
>>>> + trans_name = transaction_get_node_name(node, trans, node->name);
>>>> + if (!trans_name)
>>>> + goto nomem;
>>>>
>>>> - list_for_each_entry(i, &trans->changes, list) {
>>>> - if (streq(i->node, node->name)) {
>>>> - if (recurse)
>>>> - i->recurse = recurse;
>>>> - return;
>>>> - }
>>>> - }
>>>> -
>>>> - i = talloc(trans, struct changed_node);
>>>> + i = find_accessed_node(trans, node->name);
>>>> if (!i) {
>>>> - /* All we can do is let the transaction fail. */
>>>> - generation++;
>>>> - return;
>>>> + i = talloc_zero(trans, struct accessed_node);
>>>> + if (!i)
>>>> + goto nomem;
>>>> + i->node = talloc_strdup(i, node->name);
>>>> + if (!i->node)
>>>> + goto nomem;
>>>> +
>>>> + introduce = true;
>>>> + i->ta_node = false;
>>>> +
>>>> + /* We have to verify read nodes only if we didn't write them. */
>>>> + if (type == NODE_ACCESS_READ) {
>>>> + i->generation = node->generation;
>>>> + i->check_gen = true;
>>>> + if (node->generation != NO_GENERATION) {
>>>> + set_tdb_key(trans_name, &local_key);
>>>> + ret = write_node_raw(conn, &local_key, node);
>>>> + if (ret)
>>>> + goto err;
>>>> + i->ta_node = true;
>>>> + }
>>>> + }
>>>
>>> I think the current code structure is a bit confusing.
>>>
>>> For write types, the call to write_node_raw is outside of this function
>>> but for read type it is inside this function.
>>
>> This is due to the different purpose of write_node_raw() in both
>> cases:
>>
>> In the read case we write an _additional_ node into the transaction,
>> while in the write case it is just the user's operation.
>>
>>>
>>>> + list_add_tail(&i->list, &trans->accessed);
>>>> }
>>>> - i->node = talloc_strdup(i, node->name);
>>>> - if (!i->node) {
>>>> - /* All we can do is let the transaction fail. */
>>>> - generation++;
>>>> +
>>>> + if (type != NODE_ACCESS_READ)
>>>> + i->modified = true;
>>>> +
>>>> + if (introduce && type == NODE_ACCESS_DELETE)
>>>> + /* Nothing to delete. */
>>>> + return -1;
>>>> +
>>>> + if (key) {
>>>> + set_tdb_key(trans_name, key);
>>>> + if (type == NODE_ACCESS_WRITE)
>>>> + i->ta_node = true;
>>>> + if (type == NODE_ACCESS_DELETE)
>>>> + i->ta_node = false;
>>>
>>> The same caveat made me wonder if ta_node was really what it meant to
>>> be because I couldn't find where write_node_raw was.
>>>
>>> Can I suggest you make them consistent? Either lift the write_node_raw
>>> for read to read_node or push down the write_node_raw in delete_node and
>>> write_node here?
>>>
>>> If I misunderstand how this works, please tell me...
>>
>> As I already said: in the read case writing the node is depending
>> on the context and lifting it up would seem rather strange: why
>> should reading a node contain a write_node_raw() call?
>>
>> In the write case I believe we should keep write_node_raw() where
>> it belongs: in the appropriate function modifying the node.
>>
>> All actions in access_node() are transaction specific and _additional_
>> in the transaction case.
>
>
> OK, my line of reasoning is that whatever DB operation is necessary to
> make a functionality work should be consistent. That means even having a
> DB write in read is OK. But I think your explanation is fine, too.
>
> May I then suggest adding the following to the write for read type in
> access_node?
>
> /* Additional transaction-specific node for read type. We only have to
> * verify read nodes only if we didn't write them.
> *
> * The node is created and written to DB here to distinguish from the
> * write types.
> */
Will do.
Thanks,
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |