|
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
|
|
|
|
|
jschell wrote: What is the business use case for that?
Not having app instances overwrite each other's data.
Without a safeguard, it's happening.
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 having app instances overwrite each other's data.
If yours does your database is not normalized 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
jschell wrote: 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.
I totally disagree. Your example is perfect case FOR locking..
User A with parent standing there clicks "EDIT". All other instance's EDIT buttons become disabled.
User B with parent on phone can now not modify the record until the other user is done.
I'm currently working on a mid-sized app for a construction company. There are 5 users in two buildings on site. The app existed when I got there. One problem they have is exactly this scenario...multiple users attempting to update a job record at the same time. It IS happening because the app isn't doing anything to prevent it.
I hear you and others here saying there's no use case for this and I'm left scratching my head because this scenario most definitely exists and needs to be handled.
The only use case where this doesn't need to be addressed is when there's only one user.
jschell wrote: What is the business use case for that?
Not everything built into an app comes out of the customer requirements. There are expectations that the app will function correctly, and we as developers are responsible to ensure that happens. If you're not building in safeguards, then bad things WILL happen.
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: I totally disagree. Your example is perfect case FOR locking..
Actually it is an example for not doing it.
First it is is extremely unlikely to actually occur.
Second developers should not be adding work load for improbably scenarios and certainly should not do it with business owners driving it.
Third as I already pointed out, the only correct solution requires a court case. Neither the software nor the dentist office employees can determine the correct resolution.
Kevin Marois wrote: Not everything built into an app comes out of the customer requirements. There are expectations that the app will function correctly, and we as developers are responsible to ensure that happens. If you're not building in safeguards, then bad things WILL happen.
You can't do that.
First, the business not the developers are ultimately the arbitrators of risk. A developer might point out a problem but the business owners must decide if it is worth it.
Second, code costs money. Every single line of code adds additional cost a produce. Every new requirement adds cost to the product. At the end of the day the business wants the software to work in a reasonable way. At the end of the day. Not 10 years from now when it is finally delivered because the developers started fixing every possible problem they could ever imagine.
Kevin Marois wrote: If you're not building in safeguards, then bad things WILL happen.
Been doing this for a very long time. And my deliverables are robust in that they protect against technical failures. More so than anyone I have ever worked with. But I have learned that making up business requirements do nothing but reduce the bottom line. The domain experts, not me, are much more likely to be able to analyze risk, need and reality than me. And it doesn't require a lot of thought to see that imagined scenarios by me never happen.
Kevin Marois wrote: One problem they have is exactly this scenario...multiple users attempting to update a job record at the same time.
Then you have a business case that needs a solution. That one business case however should not lead to every single case requiring a solution.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
