DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Data
  4. Data Conflict Solution for ADF BC REST With Versioning

Data Conflict Solution for ADF BC REST With Versioning

Let's take a look at a data conflict solution for ADF BC REST with versioning.

Andrejus Baranovskis user avatar by
Andrejus Baranovskis
·
Aug. 13, 18 · Tutorial
Like (1)
Save
Tweet
Share
4.82K Views

Join the DZone community and get the full member experience.

Join For Free

I would like to share sample solution for data conflict processing in ADF BC REST using versioning. When multiple users are editing concurrently the same data row, it is important to inform the user before the overriding changes are already committed by another user. There are other approaches to implement data conflict control, and you should evaluate if the solution explained below is suitable for your use case before applying it.

Sample code can be obtained from GitHub repository.

I'm using a custom change indicator property to evaluate if the client data is expired. The change indicator value is sent to the client together with the request data. PATCH request must include current client-side change indicator value if the change indicator will match the value in the backend — PATCH is allowed, otherwise, a new change indicator will be returned to the client and the response will be marked with 409 Conflict status code. Based on this, the client could decide either to resubmit the PATCH request with a new change indicator and overwrite the current data in DB or refresh the client-side data and try to submit changes later.

In this example, PATCH was executed with a valid change indicator, and response status is 200 OK. A new change indicator value is returned to the client (it should be submitted for the next PATCH call for current row):

To test the data change conflict, I would go directly to DB and change the same record. The change indicator will be updated too:

The client doesn't know about the change indicator update (the data was changed by another user). The client will include currently known change indicator values and execute PATCH. This will result in 409 Conflict status. the backend returns the latest change indicator value in the response:

The data wasn't updated, and the PATCH request was stopped on the backend:

The client knows the latest change indicator value and can submit it again — this time successfully (no one else changed data in the meantime):

Status 200 OK is returned, along with a new change indicator value. Data is changed in DB as expected:

Backend implementation is not complex. You need a DB trigger, which will get a value from the DB sequence and assign it for each changed row:

ADF BC REST includes a change indicator attribute, and it is marked with Refresh on Update support. This allows us to get the latest value assigned from the DB trigger and return it to the client:

In the doDML method, we compare the change indicator attribute value currently stored in DB and the one that comes from the client. If the values do not match (client doesn't have the latest value), the update is not allowed:

When the update is not allowed, we also must change the HTTP response code to be 409 Conflict. This will allow us to execute an error callback on the client side and take the required action to process the data conflict on the client. The HTTP response code is set from custom ADF BC REST filter:

REST Web Protocols Data (computing) Indicator (metadata)

Published at DZone with permission of Andrejus Baranovskis, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • AIOps Being Powered by Robotic Data Automation
  • A Beginner's Guide to Back-End Development
  • Top 10 Secure Coding Practices Every Developer Should Know
  • Artificial Intelligence in Drug Discovery

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: