When user clicks on the screen, a request is made to the database layer to store the data. However, when user accidentally double clicks or multiple clicks within a very short amount of time(like less than a second), multiple requests are being made to the database layer to store the same data. This is creating unwanted duplicates in the database.
The backend does have a check to see if a record already exists before inserting...But since multiple clicks on the screen generate requests at the same time, this unique check in the service is doing no good as it does not find the record.
How can I handle this situation with all the quick multiple clicks?
Usually a task like this would block anything else from being started, so it would be good to setEnabled(false) on the button being used to submit the entry. This will ensure any button clicks will be ignored. Just call someButton.setEnabled(true) when the query returns.
Related
I'm building my Messenger app. There's table called "Loaded" in MySQL server, which basically stores a pair of VARCHAR: Who_requested - Who_loaded. It means that the user named "Who_requested" has loaded user named "Who_loaded" into their main chat page. So when "the main user" scrolls down to see more users below their chat page, the server will know what to load next (I'm implementing pagination in RecyclerView). It looks something like this:
The thing when user stops the app, I'd like to wait for like 15 minutes before releasing all information related to "the main user" in loaded table and restart the app (like the effects that you might notice in Youtube after putting Youtube in the background for a while). How to implement this?
Some methods are
One
The obvious way is to have a task/service running that prunes the out of date entries. The disadvantage is that this could die and never run again. So you have to have some way of restarting it.
Two
If you don't want to do the above, then another method is to use a trigger.
Have an AfterInsert Trigger on the table
Delete out-of-date entries
The advantage is that you don't need another task that could fail. The disadvantage is that if there are no new entries, then the table does not get pruned.
Three
When you fetch the entries to display/action, only fetch the ones that are newer than 15 minutes. This doesn't prune them, but everything works fine. And you use a task or trigger to delete them.
I have a requirement where in my page i have table having list of records.
When user clicked on one record, record should be locked and someone else with old view of overview screen tries to click on the record, it shows a pop up with a message 'Sorry this record is in progress'.
I thought of adding a column in db table where i will make entry say 'In prodress' when someone click and see particular record and later when he close that record i will update that column with say 'Free'. But i have a issue here if somebody select record and close browser directly without closing properly and releasing that lock in that case nobody will be able to see that record.
Please let me know if there is any other way to implement this or how we can implement this in above mention case.
Condition 1 : Two user login at same time record is available to both in normal color say green. User 1 click on record and start editing. In this case there should be some kind of lock so that if user two tries to open same record he will get pop up message 'In progress'.
Condition 2 : User 1 login and see record in green color. Then user 2 login and see same record in grey color. Now he should not be able to click that record.
The problem you have is exactly why it is usually not done that way. If you really have a hard lock on the record, your best options is to have some kind of timeout. How long the timeout is, depends on your application. Have your client refresh the lock regularly, and you can make the timeout shorter.
A better solution might be not to lock at all, but to check whether someone has already changed the data before saving your changes. This is usually done using a timestamp or version number in the record to be updated. The concept to look for is "optimistic locking".
However, this only works if possible conflicts are relatively improbable. Call center workers updating customer records are a typical case, since it is hardly ever the case that two call center places talk to the same customer at the same time. If it ever happens, one of them will get an error, and has to re-load he data and make the changes again.
I need to have an event that is called at the moment when the user of the phone has clicked 'Clear Data' in the 'Application Manager'. Is there a way to do that?
I need to know that because I got a database that holds very important information and I need to know when that information is deleted. I tried to look for database events for that and even events for data deletion with no luck.
There is no such event.
The first opportunity to detect this is when your app is started next.
(If you're using SQLiteOpenHelper, your onCreate method will get called.)
However, there is no guarantee that the user will actually use your app again.
How to handle a situation where user might accidentally click submit button more than one time? If it happens then two rows will be generated in table. How to avoid it.
I am working in JSP.
Also want to avoid back button and refresh page which cause to create a problem of double entry in database.
I'd suggest never to rely on anything client-side too hard. Using very accessible tools you can pretty much change any behavior that is client-side enforced. If your application crashes/has undefined behavior after something client-side fails, you should change your application.
One thing you could do is to make a class that takes all the fields resulting from this POST, override it's equals() method to honor all the fields, hold the request at the user level and compare all other incoming requests to the list of requests you already have for that user.
You can then remove the request objects as soon as they have been successfully processed.
If you, on the other hand, somehow get the same request again by the user (by looking through the list of 'open' requests whenever the user POSTs a request), you can just ignore it.
Several way:
You can use javascript to forbid two cliks in the submit button, but it does not work if the user use the "back" button of the navigator between the two clicks.
On the server side, you can send the form with an unique id kept in the user session (could also be used for CSRF counter-measure). Then when submitting the form you can compare then remove the id in the user session. Be carreful for concurrent access to the session (each request has its own thread).
Detect in the database, but it depends of the data and the constraints on it. One extension of the point 2 would be to keep the generated ID of the form in the database and removing it during the first access. This method has the advantage to user the transaction support in case of concurrent access.
If the form update an specific entry in the database (row id is sent with the form), the problem could be considered as solved by itself, as it update twice the same row with the same data.
First, on the client side, disable the button as soon as the user once clicks on it.
Second, on the server side, Some information in that form for will be a primary key in your database table. So when the same information is sent again to the server while inserting the data, you will get an exception since there cannot be duplicate values of primary key.
First solution . Disable sumbit button .. second check some unique key if possible ...
If you want to make 100% certain that the submit button cannot be clicked twice, you could disable it in the javascript within the onclick= method of the button.
For instance, in the javascript (jquery) below, if the button id was 'send'...
$('#send').click(function(e) {
this.disabled = true;
businessLogicCall();
});
Have a wait time for which you don't accept any more clicks on the button, for example disabling the submit button.
Disable the submit button until user changes the input information, thus showing he wants to submit another portion of information.
Say you retrieve 100 records, and display them on a page. The user only updates 2 of the records on the page. Now you want to update only the two records, and not the other 98.
Is it best to have one submit on the page, then somehow know which 2 are updated, then send only those two to the db for an update?
What does the "somehow" look like?
Or, would you have an update-submit button for each row, and have it only update the record its tied to?
Of course there are different ways you could do this. In general, you can save yourself some trouble and server-side processing by using Javascript to assemble your POST data for only the records that have changed. Two thoughts on how this might work:
1) Go the ajax route and do live-editing. So records are presented in a table and appear to be non-editable. When a user clicks a particular row, that row becomes editable by using Javascript to create the appropriate html form on the fly. Then have either a submit button or some other handler (say, moving focus to another table row) which will trigger the POST which updates the DB (asynchronously via your preferred ajax method). Happily the mainstream Javascript frameworks can help a lot in this area.
2) Checkboxes - whenever a row is edited, its checkbox becomes checked. When the submit button is clicked, use javascript to post the POST data by grabbing everything in row whose checkbox is checked. A user can un-check a box to cancel changes to that row before submitting.
Ajax it using jQuery or some other JavaScript library and put and update button on each row.
There are many answers to this question and to some extent they depend upon your development tools and the "feel" of the site.
If you were implementing Ajax calls to do the updates on a line by line basis then this would logically seem right to have a button per line and then update it with an Ajax call when a line was changed.
This is also just the scenario that disconnected data sets were designed to solve and ADO.net handles these very well.
So as ever, the answer is "It Depends!"
You can use JavaScript to mark each field as changed when a user changes an input field. Create a hidden fields that has the id of the row you are updating, and dirty flag. (like is_dirty_$id) In JavaScript, create an onChange handler that sets the hidden field as dirty. when any input is changed.
Alternatively, you can create hidden fields for each real field you display. the hidden field would contain the initial values. check each field on the server side to determine what has changed.
You probably want to store a last_modified date as a hidden field for each record. This way if another user updates the same record, you can display an error message saying "this record has been updated by another user" or similar.
One submit button. I could foresee case I might use more then one, but in the general case just one. (Note, this looks like a web page question to me, so I'm answering with that assumption.)
There are 3 ways that come to mind which you could handle the tracking changes:
JavaScript: Put a onChange() function on the controls that update a hidden field. If that hidden has a value, then update the associated record. Requires JS on the browser, and doesn't tell you which fields to update, just which records.
Lots of form fields: Put a hidden field out with each control and compare them all when they come back. This would be ugly, but it would allow you to know which fields to update (not just the record). It would also allow you to know if someone undid a change that started.
Sessions: You could place the original values in session variables, then do the comparison when the values come back. This would be a little more elegant then lots of hidden fields, and less open to people playing with the posted back data (since you should never trust anything that comes back, even in hidden fields). Requires cookies on the browser and sessions on the server technology.