Bug 1356079 - Introduce common transaction framework as an alternative to lock-acquisition by individual translators on client stack
Summary: Introduce common transaction framework as an alternative to lock-acquisition ...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: GlusterFS
Classification: Community
Component: core
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-13 11:23 UTC by Krutika Dhananjay
Modified: 2019-05-09 20:04 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-05-09 20:04:18 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description Krutika Dhananjay 2016-07-13 11:23:39 UTC
Description of problem:

Original inventor of the idea - Xavier Hernandez <xhernandez>

The basic idea is to introduce the notion of transactions into libglusterfs for fops that need to be executed on multiple bricks atomically.
This way xlators needing transactions will use a common API. Whether the API uses locks or other mechanisms as a means to ensure atomicity is implementation-dependent and abstracted out. This makes the cluster translators light-weight, and reduces code duplication. It also makes it easy to implement newer translators that might need transactional semantics in some of their fops. This could also enable multiple transactions of a single fop (one txn from AFR and one from DHT, for example) to be serviced by a single lock. Some of the consumers of this framework could be AFR, DHT, EC and sharding.

The details are still being worked out. Will post the design once it is ready here and on mailing lists.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Amar Tumballi 2019-05-09 20:04:18 UTC
This feature is moved to https://github.com/gluster/glusterfs/issues/342


Note You need to log in before you can comment on or make changes to this bug.