|
It could be interesting. But on the other hand...
Kevin Marois wrote: Any reason you wouldn't use this approach?
I was deeply entrenched in the Microsoft world for well over a decade. Now I have noticed that "the rest of the world" is moving towards Linux and open source. I would assume that there are many alternatives to SignalR. All the script-kids today are talking about NodeJS. Not that I am huge fan of dynamic typing but it is one name that comes up. I think a comparison between different approaches would be fun, but that is only my highly personal and humble opinion. 
BTW there already is a short article here:
What is SignalR and Why Should I Use It?
... such stuff as dreams are made on
|
|
|
|
|
OK, thanks for the article.
My question was do you think a solution for locking that uses SignalR would be a beneficial approach, and is it worth writing an article on?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Ah! I missed that you were into locking specifically. I could be wrong, but my gut feeling is that something more lightweight could do the trick so I tossed out this query:
lightweight signalR - Google
On the other hand, if you already have an ASP.NET server then my point is a non-issue...
... such stuff as dreams are made on
|
|
|
|
|
OK, thanks.. I think SignalR is already pretty lightweight, but that would be a point I'd make in the article
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I did some research for a project and looked/scanned over SignalR but didn't use it.
Would be interested at an article to become better acquainted with it.
New version: WinHeist Version 2.2.2 Beta I told my psychiatrist that I was hearing voices in my head. He said you don't have a psychiatrist!
|
|
|
|
|
Go for it. Sound like good stuff !!! and I want to learn SignalR too
Bryian Tan
|
|
|
|
|
More knowledge is always welcome! I haven't used SignalR before but it sounds like a useful use-case for it. Especially if you succeed in making it a generic like you mentioned! 
|
|
|
|
|
Some thoughts for you to consider (based on having worked on apps that faced these issues in the past):
What would you be sending out a lock message on? When a user starts editing? Bear in mind that you are going to have a distributed environment where it is entirely possible that you would have two users looking to edit the same record about the same time - and due to latency issues, they both start the edit before they receive the lock message. How are you going to handle that?
What about the situation where someone takes out a lock but the application crashes so that they don't release the lock? What strategies are you going to put in place to handle this? There's a similar situation where the user starts an edit and then takes a phone call so that they keep this record in an editing state for a period of time?
What about if you are editing a record that is used as part of a relationship? A lookup table value for instance? Will the consuming applications need to be aware that the record may be changing?
This space for rent
|
|
|
|
|
I think you would use "traditional" locking mechanisms but use signalr only for the notification of waiting clients. So if you hit "Edit" it would say someone is editing that data and you'll then be informed automatically when the resource has become unlocked. Obviously it doesn't solve the issue of unreleased locks etc, but nothing is really going to solve that.
|
|
|
|
|
F-ES Sitecore wrote: So if you hit "Edit" it would say someone is editing that data and you'll then be informed automatically when the resource has become unlocked
There's a latency issue, leading to a potential race condition that's the core of that problem - when two people hit edit at roughly the same time, so you get crossed notifications here. I have seen situations like this many times, so whatever solution the article is going to propose has to be able to cope with situations like that.
This space for rent
|
|
|
|
|
Pete O'Hanlon wrote: There's a latency issue, leading to a potential race condition that's the core of that problem - when two people hit edit at roughly the same time, so you get crossed notifications here. I have seen situations like this many times, so whatever solution the article is going to propose has to be able to cope with situations like that.
How would any solution handle this?
One possibility is after a lock is reported back to the client, do another quick check to see if there any duplicates, and use the Date/Time to see who got it first, then quickly re-disable the view of the client that should not have the lock.
Your thoughts?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Pete,
I dusted off this idea I think I'm going to put together a prototype, but I wanted to respond to your points before I do and see what you thought...
Pete O'Hanlon wrote: Some thoughts for you to consider (based on having worked on apps that faced these issues in the past):
I too have done locking mechanisms. They usually involve writing to a locking table. My idea here removes that table from the architecture, but the issues you pointed out still exist. Here's my thoughts...
Pete O'Hanlon wrote: What would you be sending out a lock message on? When a user starts editing?
I would think an Edit button of some sort would be the initiator. The button is disabled until a SignalR message says the record is no longer locked, at which point it becomes enabled. Clicking it performs a lock.
Pete O'Hanlon wrote: What about the situation where someone takes out a lock but the application crashes so that they don't release the lock? What strategies are you going to put in place to handle this? There's a similar situation where the user starts an edit and then takes a phone call so that they keep this record in an editing state for a period of time?
The basics of the hub would have methods to add/remove a lock using the View Name and User Name, and a method to remove all locks for a user. On startup all preexisting locks for a user are removed (in case they previously crashed) and the app would need an administrator function to do the same.
Pete O'Hanlon wrote: What about if you are editing a record that is used as part of a relationship? A lookup table value for instance? Will the consuming applications need to be aware that the record may be changing?
I've always assumed that if a parent view is locked, then so are its child views.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Like.
WebSocket can be a b1tch.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Kevin Marois wrote: do you guys think this is an idea worth of writing up?
Absolutely.
BTW, my dabbling with SignalR was a great experience. It "just worked." Used it for notifying clients on desktop and tablet devices. Very very cool.
I think the record lock/unlock notification is a really unique and interesting idea! Go for it. 
Marc
|
|
|
|
|
If you stab someone during an argument, does he finally get the point?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Not sure, but he probably works up a good thirst for some tang.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
modified 14-Feb-17 12:38pm.
|
|
|
|
|
If you use your rapier wit, then yes
|
|
|
|
|
It would certainly be a cutting remark.
veni bibi saltavi
|
|
|
|
|
What a cutting remark!
EDIT: argh - beat by Nagy 
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Livin' on the edge are we, Griff?
... such stuff as dreams are made on
|
|
|
|
|
"Why a spoon, cousin?"
"Because it hurts more, you twit!"
Software Zen: delete this;
|
|
|
|
|
I see you've played knifey-spoony before.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
I hear what you're saying and I do not wish to be blunt... *stabs with knife*
|
|
|
|
|
Huh, I was expecting a Ceaser joke in there somewhere.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Lets back up a minute. What are you trying to say, Brutus?
Mongo: Mongo only pawn... in game of life.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
