|
Kevin Marois wrote: How would you tell other instances of your app that something has happened, or to take some action?
I usually don't, but when forced to, I'd use a queue in the database and poll that. There'd be a slight delay, just as GMail has.
Kevin Marois wrote: Record added to table
I wouldn't; I dislike the idea of lists growing while you're working with it. Or worse, data changing while you are editing 
Kevin Marois wrote: Record is locked/unlocked by a user
Again, I wouldn't; has never been a problem to let the database handle that.
Kevin Marois wrote: User has logged in/out
I wouldn't; even if both apps are on the same desktop, only the active one (the one with input-focus) would be logged out.
Kevin Marois wrote: Force Logout
I wouldn't; the server would simply return an error-condition on the next request, similar to Sql Management Studio.
To answer the question; yes, it seems like SignalR is a usefull communication-package. Now running a compiled script on a webhost may have the advantage of being very cross-platform, I would certainly not call it "realtime". Anything sent to a browser and digested by JavaScript is very noticeably "not realtime".
Kevin Marois wrote: Anyone have any other ideas?
I think that SignalR might work better in a web-environment, for those who are building web-apps. For a desktop-application I'd prefer a simple socket (and not another dependency), unless there is a very compelling argument against it.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: I usually don't,
I agree with that sentiment myself. I found myself questioning even the need for some of the posted examples in the OP. Certainly when someone suggests such a need I usually question why it is needed in the first place.
|
|
|
|
|
jschell wrote: Certainly when someone suggests such a need I usually question why it is needed in the first place.
I doubt that the web has such need, but since someone built a solution, there will be specifications demanding this "realtime" logout.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
