[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