Open frankgiordano opened 4 years ago
Implemented optimistic locking for incident detail screen. Code checked in. Onward with the other objects..
Found an issue with saving an incident from the main menu's incident dropdown selection 'search by group' where we can list out incidents by a group. Saving an incident here is done within another angularJS controller where I did not take care of the new 'version' field. As a result, it failed to save if I previously saved the incident from the other menu incident search list. I checked in code to handle versioning from this controller.
I plan to work on Product object next.
Found an issue with saving an incident from 'search by group' menu selection when the version has changed, the error message return is the normal error message about required fields not the error message about the versioning issue. I will fix this.
This was a little more involved. I fixed the issue and made changes to the error messaging handling.
Product object next hopefully.
Added undefined response check to error incident save response see above check in. Make this consistent going forward..
Added Optimistic Locking for Project Object. Next need to do the same for Root Cause, Incident Resolution, and Product objects.
Implement JPA @Version and Optimistic Locking for the main objects...
As described here https://www.byteslounge.com/tutorials/jpa-entity-versioning-version-and-optimistic-locking:
Optimistic locking is a mechanism that prevents an application from being affected by the "lost update" phenomenon in a concurrent environment while allowing some high degree of concurrency at the same time. This is achieved without actually resorting to any locks: Optimistic locking relies on checks that are made against the existing data on the data store by transactions during update time.