|
I suppose such a solution could be used if you had a system where you had to roll an update out at a certain point in time. Your server could send out the notification that the update needs to happen and log the application out - and yes, I have seen systems that do this in practice.
This space for rent
|
|
|
|
|
I can see how that would be preferred to looking at an old UI with cached JS. Users all over the world would not be able to work with the product after the update, simply because they're still on an 'old page'.
Not a problem to update Sql Server and disconnect some clients if you're on a desktop 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Pete O'Hanlon wrote: Your server could send out the notification that the update needs to happen
I can see several potential problems with that solution.
1. What if the client app does not receive the notification.
2. What if the client app is in the process, right at that moment, of making a request to the server.
3. As a specific example of 2 what if the app is in the process of doing a long running process, such as uploading or downloading a large file.
4. What happens if the update is actually to the notification service itself?
|
|
|
|
|
Yup - it's not 100% safe.
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: Yup - it's not 100% safe
Name something in coding that ever is.
Not doing something about a problem doesn't make it go away
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote:
Not doing something about a problem doesn't make it go away
Code, all code, can introduce problems.
If you introduce code to 'fix' a problem then the fix itself can introduce problems. So such fixes should not be introduced unless problem is something that can reasonably be expected to occur AND if it occurs it would significantly impact business functionality.
|
|
|
|
|
We could come up with "what ifs" all day long to try to discredit any proposed solution. Some of them are valid and must be considered, but you also don't want to get into "Analysis Paralysis" where you study the problem forever and never do anything about it.
Having said that, my idea was primarily aimed at the notion of preventing other users from editing data while another user currently is. In this scenario your points don't really apply.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I suppose there are some very specific times when real time locking may be valid, I have yet to run across one in over 30 years of LOB developing. I'm with Eddie on this I wouldn't.
I have the impression that SignalR is designed to make responsive web sites, not the job you are proposing.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
How do you handle a situation where, say in a desktop app, User A starts editing, and then User B wants to access that record?
How does instance B know that instance A has unlocked the record? The SignalR approach, being "real-time", would notify all other instances that this part of the app is now available. The "Edit" button on the other instances now become enabled.
Then, as soon as a user clicked "Edit", the "Edit" button on all other instances becomes disabled.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
It's the difference between optimistic locking and pessimistic locking.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
I know that. But how would you handle it? What implementation? A Timer that does a check? I've seen apps that had MouseEnteerEvents calling into the data (Yuck).
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
One should avoid pessimistic locking as much as possible.
In a "high transaction" situation, it's a non-starter.
Unless you can describe a particular scenario where you need it, you are just looking for a lot of pain.
The optimistic lock usually only involves comparing "before" and "after" "row serial numbers".
Easy.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Gerry Schmitz wrote: In a "high transaction" situation, it's a non-starter.
This whole discussion is about dealing with users, so transactions are not going to come into play. Users are not going to be clicking Edit & Save fast enough to create a "high transaction" situation.
Gerry Schmitz wrote: Unless you can describe a particular scenario where you need it, you are just looking for a lot of pain
I can't imagine a real world app that DOESN'T need this.
If you don't protect against instances of an app silently overwriting each others changes, then you're going to have a mess in the data, and there would be almost no way to know who did what.
Gerry Schmitz wrote: The optimistic lock usually only involves comparing "before" and "after" "row serial numbers".
My proposal removes the table based approach altogether as there are no tables.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: If you don't protect against instances of an app silently overwriting each others changes, then you're going to have a mess in the data, and there would be almost no way to know who did what.
That is a correct statement of a general problem. Suitable for a university course.
Myself I don't teach, rather I create applications for the business world.
I write solutions based on business use cases.
So what is the specific, real, business use case that you have that required explicit locks?
|
|
|
|
|
This isn't some abstract concept. My statement is a real world problem that correctly written applications must mitigate.
Shrugging your shoulders and saying "Oh well I don't see it as a problem" doesn't make the problem go away, or not exist at all.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: My statement is a real world problem that correctly written applications must mitigate
It is a statement of a potential problem. It is not business case.
I have been working with large back end systems for 30+ years. Telephony, cable, financial (credit cards), medical and agricultural. I specialize in server software and databases.
I also specialize in analyzing systems for problems before they occurred.
I believe I can recall a single instance of explicit locking and that was required by an design issue and not a business case.
I can recall many instances where QA and/or developers found or insisted there could be a problem. But only by exercising a system in ways that are not related to business needs.
Consider one such system that I worked on where there was a customer call center working with credit card merchant accounts, with 200 call center employees. Certainly high stakes given that at the time it was the third largest merchant card server in the US at the time.
So what is the business case, for example, where the merchant would call the call center on TWO different phones and ask for the account information to be updated in TWO different ways? At the same time of course.
Kevin Marois wrote: Shrugging your shoulders and saying "Oh well I don't see it as a problem" doesn't make the problem go away, or not exist at all.
But making up improbably problems serves neither the business nor the developers.
|
|
|
|
|
I can give you 1 real world use case, it involved a ski lodge booking system we wrote in the 90s, 15-20 booking agents all beavering away on the phone and a limited and shrinking number of lodges available. We solved it by having the user lock the record, first in got the lodge.
A timer on the client updated the available pool of lodges.
The problem was when an agent forgot to release a lodge where the booking failed, we had a timer on the lock that, if not confirmed by the agent, released the lodge back into the pool.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Sounds like a good business case.
But you didn't apply explicit locks all updates on all tables - right?
|
|
|
|
|
jschell wrote: So what is the specific, real, business use case that you have that required explicit locks?
User A starts editing data. Sits there for a while or goes to lunch. Meanwhile User B starts editing the same data and then clicks save.
Now, User A comes back from lunch and clicks Save.
User B's changes are gone.
Real world problem that happens all the time.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Kevin Marois wrote: User A starts editing data. S
That is a description of potential problem. Not a real business case. Do you have a real business case?
Kevin Marois wrote: Real world problem that happens all the time.
I have worked in financial (credit card including merchant call centers), cable, telephony, medical and even agricultural. Been doing back end work for more than 30 years on large systems.
No business cases for those.
Consider this real business case.
1. Dentist office patient record.
2. Patient record has a residence address.
What is the business case where that address record would be
1. Updated at the same time.
2. Updated differently
3. Updated such that there is something that the software can actually decide one or the other is correct.
Should be a simple case since it happens "all the time."
|
|
|
|
|
Kevin Marois wrote: I can't imagine a real world app that DOESN'T need this.
Most "real world apps" have been doing fine without.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I don't! I have offered to build something for a number of clients who raised the issue and then put a rather high price on the work. I then suggest that they delay the decision till they actually experience the problem.
To date, in over 30 years, I have never had a client come back and ask to implement a solution. Caveat I do LOB work only.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
Kevin Marois wrote: How do you handle a situation where, say in a desktop app, User A starts editing, and then User B wants to access that record?
What is the business use case for that?
Like the other poster I have never seen a real case for that. I have however seen QA and even developers make up cases and then claim it is a problem.
There are situations where locking (general term) is required such as in an inventory/POS system where receiving must add to the inventory and the POS must subtract but a transaction takes care of that.
And what happens when the lock holder terminates abruptly. Then one must deal with self expiring locks or even lock clean up code and one must decide on a 'reasonable' time period.
I had a real app that represented a dentists office and QA claimed that the address could be updated by two people. So I came up with the following real (reasonably) valid business case.
1. Parents are divorced and fighting over child custody.
2. Parent A is in the office and insisting that child's address be set to their address.
3. Parent b is on the phone and insisting that child's address be set to their address.
The above is an example of one record that has two different values. The only problem is that there is absolutely no way for software to determine which one is correct. Locking doesn't solve anything. Notifications do not solve anything.
The only solution for the above involves a ruling from a court of law.
|
|
|
|
|
"Contact Mechanism" entities ... 
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
