[heketi-devel] To pass a *bolt.DB or a *bolt.Tx
Michael Adam
obnox at samba.org
Thu Mar 9 21:51:57 UTC 2017
Hi Talur,
Thanks for this write-up!
It sounds all very consistent.
But I will want to thoroughly look at the code.
The Mutex thing sounds a bit like complete
serialization (for write processes).
Cheers - Michael
On 2017-03-10 at 02:03 +0530, Raghavendra Talur wrote:
> Here is what Bolt documentation says about transactions:
>
> ```
> Transactions
>
> Bolt allows only one read-write transaction at a time but allows as
> many read-only transactions as you want at a time. Each transaction
> has a consistent view of the data as it existed when the transaction
> started.
>
> Individual transactions and all objects created from them (e.g.
> buckets, keys) are not thread safe. To work with data in multiple
> goroutines you must start a transaction for each one or use locking to
> ensure only one goroutine accesses a transaction at a time. Creating
> transaction from the DB is thread safe.
> ```
>
> Now, in heketi, there some operations at app.* level that might have
> to view/update many buckets(node,brick,volumes,device). The methods of
> these objects take either a *bolt.Tx or a *bolt.DB.
>
> In my understanding, there are some app.* operations where it is a
> must that all the methods that are called within it, should get the
> same view of db; in that case, it makes sense that app.* function
> starts a tx and hands it down to the lower methods thereby ensuring a
> consistent view.
>
> Some methods however, like Create and Destroy methods of brick have
> been written to take a *bolt.DB as a argument. This seems to be done
> to enable use of goroutines. Now, we have functions in the higher
> layer calling these very methods which would want the operation to be
> done in the transaction created above.
>
> In PR #710 I have made two changes to tackle the above problem:
> 1. Changed these methods to take *bolt.Tx as arg instead of *bolt.DB
> 2. Introduce a sync.Mutex as another member of StatusGroup, any
> goroutines that want to operate on the db using a shared tx must call
> the new Lock() method of StatusGroup and call Unlock() after the db
> operation is done.
>
> In summary, as bolt documentation suggests, to work with data in
> multiple go routines:
> we used to: start a transaction for each one
> now we do: mutex locking to ensure only one goroutine accesses a
> transaction at a time
>
> If there are better ideas, they are most welcome.
>
> Thanks,
> Raghavendra Talur
> _______________________________________________
> heketi-devel mailing list
> heketi-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/heketi-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/heketi-devel/attachments/20170309/86b3e646/attachment.sig>
More information about the heketi-devel
mailing list