Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use technical event date for optimistic locking #1036

Closed
S-Tim opened this issue Aug 19, 2024 · 0 comments · Fixed by #1037
Closed

Use technical event date for optimistic locking #1036

S-Tim opened this issue Aug 19, 2024 · 0 comments · Fixed by #1037
Assignees
Labels
Prio: Must This feature must be implemented in current milestone. Status: In progress Assignee is working on this issue. Type: breaking This is a breaking change. Take care while migrating. Type: enhancement New feature or request
Milestone

Comments

@S-Tim
Copy link
Contributor

S-Tim commented Aug 19, 2024

Scenario

  • camunda-bpm-taskpool version: any
  • Camunda BPM version: any
  • Description of your use case: (detailed description or executable reproducer, e.g. GitHub repo)

When updating data entries for technical reasons (for example enriching the payload with a previously non-existing attribute) we want to keep the last updated date because it is part of our domain and relevant for the users in the UI. We would still like an optimistic locking mechanism, so using a new field with the technical date of the event would be good.

Current Behaviour

Currently the date from the Modification is used for optimistic locking. When the provided date is older than the last updated date on the JPA entity, then the update is ignored.

Wanted Behaviour

Newer events (according to the domain event timestamp) should not be ignored, even if the timestamp in the modification is older.

Possible Workarounds

Database or modification timestamp modification

@S-Tim S-Tim added Type: enhancement New feature or request Status: In progress Assignee is working on this issue. Prio: Must This feature must be implemented in current milestone. labels Aug 19, 2024
@S-Tim S-Tim added this to the 4.2.2 milestone Aug 19, 2024
@MichaelVonB MichaelVonB added the Type: breaking This is a breaking change. Take care while migrating. label Aug 19, 2024
MichaelVonB pushed a commit that referenced this issue Aug 19, 2024
MichaelVonB pushed a commit that referenced this issue Aug 20, 2024
@zambrovski zambrovski modified the milestones: 4.2.2, 4.3.0 Oct 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Prio: Must This feature must be implemented in current milestone. Status: In progress Assignee is working on this issue. Type: breaking This is a breaking change. Take care while migrating. Type: enhancement New feature or request
Projects
None yet
3 participants