I have an application that manages a list of employees. Users(Admins) in the application have the possibility to create and edit those employees . I want to lock the edit access of an employee while an other user is editing him .
I found that i can use optimistic concurrency so when second user try to edit it he can not . The disadvantage of this solution is that the user can waste time on editing the employee (especially if there is many parameteres to edit) and when he clicks on edit button he will get the new version edited by the user before him.
So I am searching a way to manage concurrent access in the code and not in JPA.Like if the user want to access the edit page of the employee X he will recieve a message that the user ADMIN2 is editing this employee now . And he can not access to edit the employee while ADMIN2 still editing the user .
Is there any standards to use to manage this kind of concurrent access . If not how do you think i can manage this concurrent access ?
There is no build-in way to do this in JPA. JPA2 does support pessimistic locking, but this is a concept linked to transactions, and therefore not what you need.
Also you don't actually want to do this, and if you were around 10+ years ago when (some) source control system used pessimistic locking ('good old source safe), you will know why this is a bad idea compared to modern day Git.
What you really need is a way to merge the concurrent changes, just like a git merge conflict. Instead of throwing away the user's changes (when the optimistic lock insert fails) you send his modified version and the current version from the database back to the UI, and let the user merge the two versions, and save again.
You could also go full out on the history/auditing, both EclipseLink and Hibernate has a way of storing multiple versions of the same entity (basically like Git does), so you can track changes. I you know your way around JPA, and have a good UX designer it is possible to build a system that works much better than any pessimistic locking will - and even if you try to build pessimistic locking using an 'editing' column, you will still need to use optimistic locking in case two uses click the edit button for the same resource concurrently. ;-)
If you really want to implement, what you describe, I would add a editing column in the corresponding table where you mark that editing starts. Then before you start editing, you check this boolean and act with your message. In other words: Such a locking on DB level is hardly possible accross multiple transactions and would be a danger (I asume that editing the employee is a long process, far a way from handled inside same transaction) and you best implement it your self (do not forget to remove the editing boolean after saving or after cancel).
Related
I'm currently developing an application in the SAP BTP for multiple users. In the application you have one table where all responsibilities of a specific task are written down. These responsibilities may overlap between the users, which means that for one responsibility multiple users are mentioned.
In the application the users should click on either accept or reject if they still are responsible for this task. After they have given their feedback, they can click on a save button to write everything via a batch submit to the hana db. If they are not responsible anymore their name should be removed from the tasks and they should not see this task anymore.
The problem I am facing is that currently everything is stored in one database table and if one user gives feedback to some entries while another user works on the same entries, the user who saves his entries last will override the first one.
I have tried searching for a delta insert into the database or to live update after each user input or to lock the data when another user is currently working. But none of these seem to work fine, because users would still be able to override each others entries or they may lock some entries forever.
My question therefore is, what is the usual approach to manage multiple user inputs on a single table or is using a single table a bad practise at first?
My second question would be if sapui5 supports this approach or if I can handle this in another way?
You need to do server-side validation, before the save action.
UI5 does not support this directly, you can handle it by yourself.
Because we are stateless with ui5 / data you could use the draft concept
https://experience.sap.com/fiori-design-web/draft-handling/
Or something like already said backend logic with checks before safe.
I have a project that I'm working on that uses a background thread to insert data into the database from a different source. Now one of the problems that I have occasionally, once the user interacts with the database an error due to "could not serialize access due to concurrent update" is triggered.
Because my data source generates a lot of data my background thread is always busy keeping up and inserting the data and I've written the algorithm to basically "retry" whenever a row is locked, so I can live with the occasional error that occurs on the background thread.
The real problem is that my users basically interact with the database via a website that has ORM mapping in various layers and it seems that occasionally the user might be modifying the same record that is being worked on by the background thread.
Is there any recommendation of what I could do make my not be confronted with the serialization errors?
Presumably your users have been presented with some data from the database, and based on what they saw have decided to change something. If the data they looked at is obsolete, why would you expect that decision based on obsolete information to still stand? In general, they need to look at the more-current data and decide if they still want to make the change.
If those decisions are "easy" to make, then why do you have humans making them in the first place? And if they are hard to make, what choice is there but to have the people re-make them? There may be particular answers to this, but I don't see any general answers, and you haven't given us any particular details to work with.
I read somewhere that there is no lock system included yet. This info was dated 2009, six years ago. Has that been implemented? Or how can I now implement a lock system?
How can I enshure that between my select and my update anybody else makes changes? I do not want to lock the system after calling a getter, that blocks the entire System..
Application-level locking is still not included (and for a good reason - you usually need to lock complex business objects and not the individual entities they consist of). Just use the enqueue objects like in any other ABAP application (and preferably encapsulate them).
I've been thinking about the applications for goangular. In the need for immediate storage/database updates, such as a chat application or stocks application etc., I can see how goangular can be extremely useful in the sense of SignalR methodologies. But could it be applied to the traditional form with ten fields and a save button on it? All I could think of, was the traditional form, with ten fields on it -less the save button. If all ten fields are on the scope of the controller, than there would be no need for a save button. Every change of a field would be commemorated to the goinstant storage. Now having said that, how would one UNDO lets say any changes to those ten modified fields? Control+Z ten times? Not so robust. Any ideas on a UNDO all Changes button for such a form? (desperately trying to expand the bonds of real time database transactions)
I'll attempt to answer what I believe to be the spirit of your question first.
Most of the time, when using GoAngular, we're focused on synchronizing application state. Aka: Active clients sharing session data. Inevitably we drift into the territory of long-term persistence. At this point, rigorous validation / sanitization become a necessity, which we can't discuss without some context.
Let's say our user is completing their profile. This profile will be used to create a User model, which we will persist. Now that we have context, it becomes clear that we shouldn't persist a partially complete form, because it wouldn't represent a valid User model. We persist the form once it is complete, and valid.
Implementing this is as simple as creating a custom $scope.onSubmit method and validating the form input before calling $save on our new $scope.user model.
Undo would be easy to implement too, if you use $scope.users.$add, a key will be generated and returned, you could use this key to remove the new user. If you wanted to roll-back a change, you'd need to implement some system for versions, and roll back to the previous version of that User.
Hope I've answered your question in here somewhere :)
I am writing an app for iOS that uses data provided by a web service. I am using core data for local storage and persistence of the data, so that some core set of the data is available to the user if the web is not reachable.
In building this app, I've been reading lots of posts about core data. While there seems to be lots out there on the mechanics of doing this, I've seen less on the general principles/patterns for this.
I am wondering if there are some good references out there for a recommended interaction model.
For example, the user will be able to create new objects on the app. Lets say the user creates a new employee object, the user will typically create it, update it and then save it. I've seen recommendations that updates each of these steps to the server --> when the user creates it, when the user makes changes to the fields. And if the user cancels at the end, a delete is sent to the server. Another different recommendation for the same operation is to keep everything locally, and only send the complete update to the server when the user saves.
This example aside, I am curious if there are some general recommendations/patterns on how to handle CRUD operations and ensure they are sync'd between the webserver and coredata.
Thanks much.
I think the best approach in the case you mention is to store data only locally until the point the user commits the adding of the new record. Sending every field edit to the server is somewhat excessive.
A general idiom of iPhone apps is that there isn't such a thing as "Save". The user generally will expect things to be committed at some sensible point, but it isn't presented to the user as saving per se.
So, for example, imagine you have a UI that lets the user edit some sort of record that will be saved to local core data and also be sent to the server. At the point the user exits the UI for creating a new record, they will perhaps hit a button called "Done" (N.B. not usually called "Save"). At the point they hit "Done", you'll want to kick off a core data write and also start a push to the remote server. The server pus h won't necessarily hog the UI or make them wait till it completes -- it's nicer to allow them to continue using the app -- but it is happening. If the update push to server failed, you might want to signal it to the user or do something appropriate.
A good question to ask yourself when planning the granularity of writes to core data and/or a remote server is: what would happen if the app crashed out, or the phone ran out of power, at any particular spots in the app? How much loss of data could possibly occur? Good apps lower the risk of data loss and can re-launch in a very similar state to what they were previously in after being exited for whatever reason.
Be prepared to tear your hair out quite a bit. I've been working on this, and the problem is that the Core Data samples are quite simple. The minute you move to a complex model and you try to use the NSFetchedResultsController and its delegate, you bump into all sorts of problems with using multiple contexts.
I use one to populate data from your webservice in a background "block", and a second for the tableview to use - you'll most likely end up using a tableview for a master list and a detail view.
Brush up on using blocks in Cocoa if you want to keep your app responsive whilst receiving or sending data to/from a server.
You might want to read about 'transactions' - which is basically the grouping of multiple actions/changes as a single atomic action/change. This helps avoid partial saves that might result in inconsistent data on server.
Ultimately, this is a very big topic - especially if server data is shared across multiple clients. At the simplest, you would want to decide on basic policies. Does last save win? Is there some notion of remotely held locks on objects in server data store? How is conflict resolved, when two clients are, say, editing the same property of the same object?
With respect to how things are done on the iPhone, I would agree with occulus that "Done" provides a natural point for persisting changes to server (in a separate thread).