In the video, when he talks about spectators all watching one person (same stream), he says they would use "multicast within our datacenters". Well, I could see the point of using multicast up to the end-points through the whole path (which, at least in germany, sadly won't work, because providers here don't support it), but using it within the datacenters? How will that help 100.000 people watching the stream, you will still need to unicast it expensively to every single viewer from the border of the datacenter.
Can someone clear this up for me? Would multicasting work on US-Internet?
+5 Is not enough for the value of the parent post. Optimistic Locking is the right answer in 99% of the cases
I doubt that, see below.
The issue then becomes how you want to deal with re-submitted of changes. If the entities to be saved are small and very atomic, asking the user to retype, making sure their changes are still sensible on the modified record makes sense.
In many cases (>1%) the smallest cluster of changes that still has to be in one group to make sense is anywhere from small. Entering such changes might even involve making phone-calls, looking up data someplace else, making some calculations on a sheet of paper, etc.. and so it can be time-consuming and optimistic locking is a very bad choice in such cases.
So q.e.d: Optimistic locking is not the right choice in many cases.
If your records are very large and/or very complex, then you might consider using some business knowledge to see if changes to the record can be grouped logically, and maybe even committed individually: If someone changed data for X shipment of a purchase order, while someone else changed Y, then the changes don't really have to conflict.
Sometimes the business-logic of a single object can be very complex and the data all intermangled. You can't just assume everything can be divided in small-enough independent pieces of data, just because you are too lazy to implement some sophisticated solution.
But whatever you do, build it around optimistic locking: Don't try to lock a record because somebody just has it open somewhere on a remote location. That path leads to madness.
Madness on the developer's side maybe, but optimistic locking can lead to madness on the user's side, even violence, trust me on this.
I must agree with you on one thing, though: implementing optimistic locking first thing as a basis makes sense and can save you a lot of trouble.
after reading most of the comments I can sum it up:
Optimistic Locking: described here by many readers, easy to implement, also good idea to implement first even when using other scheme. It will piss off users from time to time, though, because they loose data. This is the choice of the (lazy) developer and/or the cheap customer.
Real row-based or even finer locking: Hard to implement right with all the timeouts, user-infos, keeping unfinished edits over sessions,.... This is the choice of the demanding user that doesn't want to loose any work at all, and the wise customer.
Realtime concurrent editing: not really sure about this.
The chapter you're pointing to describes mysql table-locking as far as I can tell at a glance.
Table-locking is pretty much out of the question for the purpose here, since you would effectively prevent any editing to take place on any row within that table while some user would edit some (other) row in the table.
"There would be a temp-table for every editable data-table in the db, that has the same structure plus a ID_User field. When a users starts editing a data-set, the data is copied into that temp-table."
dear lord that sucks.
Between the question, and most of these answers I can see why software is in the state it's in.
Nice solution you have there... for 1994.
I must agree with you, it's very "manual", old-school, error-prone and inefficient.
To my defense: the app was started even before 1994, back then it was using an M$-Access frontend. The temp-table stuff was invented back then to get around the effects of the optimistic locking Access was doing and also to get around the horrible performance Access was showing with larger tables.
When we migrated to the javascript frontend (still on IE6 TODAY!!!, it's horrible!) we just kept that system.
I was not suggesting this would be the way to go.
I find it interesting to be able show a solution for a web-app-related problem that was initially developed as a workaround for an unrelated problem that popped up even before webapps were in larger-scale use.
This is how we did it in an in-house AJAX app for a big corporation.
There would be a temp-table for every editable data-table in the db, that has the same structure plus a ID_User field. When a users starts editing a data-set, the data is copied into that temp-table. Other users trying to edit that data will get a view-only version of the page and info on who is editing the data. On "submit" the data is copied back to the "real" table, the lock thereby released.
Should a user decide to abandon his session, crash his browser or anything like that, he will have his unsaved edits back on next login. He will even be redirected to the edit page automatically after login, if there are pending edits.
A user can "steal" his own lock (actually session, that is) when he tries to log in with a fresh session (e.g. from another workstation at a colleague's). The old session will bail out automatically saying "session hijacked" (on any next ajax action) and the fresh session will get loaded with the old one's data.
Other users can only steal locks after a timeout (to avoid problems with people going on vacation with locked data on them)
----
This eactually worked pretty well from a user's perspective, because as opposed to with optimistic locking there would never be a situation where a user would have done some edits in vain or have extra work rechecking it.
From a developer's perspective it was a pain in the ass (maintain 2 almost identical tables, maintain checkout/checkin-code everytime).
From support's point of view, it wasn't too bad. Seldomly people would call and demand release of a lock because someone just went to have coffee and he had to edit the data real quick or managment would kill him on the spot because the data would be frozen in like 7 minutes to generate reports.
For example, for every fax successfully sent via the fax server without IT intervention, the IT department gets one point.
For every fax that needs IT intervention to be sent, the IT department loses one point.
I like this idea, because it has the side-effect of forcing managment to define in writing and exactly the services the IT-department / infrastructure is actually supposed to provide and also forces them to define some metrics and mechanism to measure this. This enables the IT-department to respond to inappropriate requests in a nicely formal way. Also the managment can prioritize on this to help IT fend off the odd jerk that thinks their particular problem is the most important in the world and should be taken care of ASAP. Such a system would also provide transparency to managment and users as to wtf these IT-jerks are doing all day and why.
I think poster has a point. A nice metric might be the count of tickets that are never opened. An IT-department, IMHO, should be working on making itself obsolete.
but, mommy, there's no trackpoint! how am I going to move the mouse without my hands leaving the keyboard? and how am I going to avoid moving the mouse by accident?
of course: when looking to factor some number n = p * q (with p and q being primes) in order to crack some rsa key, this finding might well help in organizing (prioritizing) your search-space more efficiently and thus speed up the cracking.
* implement QoS sanely, give ssh, imap,... enough and the rest to p2p)
* put up a transparent proxy with a large enough cache on ports 80 and 21 (squid?)
* install adzapper to safe bandwidth from all the ads
* wait till someone complains about not getting any ads
You'd think we would... you know... communicate with our allies? Maybe?
Yeah, but as other news say, communication between french and british military is down currently thanks to conficker. Apparently they can only use fax. Maybe they have no fax-machines on their subs.
Another possible reason is that the british sub has been driving on the wrong side of the road, uhm, ocean?
So the argument is that it's reasonable to expect that my IP can be mapped to my person? Well, after this ruling it's definitely reasonable to assume this.
So this is something like a self-fullfilling prohphecy, right?
Open source is verified, by many people, who discuss it in public. Closed source is not.
The OPs problem is lack of credibility with his customer, not lack of knowledge. What he therefore needs is some credible source he can use to "proove" to his customer that above holds true.
Slashdot Mirror
In the video, when he talks about spectators all watching one person (same stream), he says they would use "multicast within our datacenters". Well, I could see the point of using multicast up to the end-points through the whole path (which, at least in germany, sadly won't work, because providers here don't support it), but using it within the datacenters? How will that help 100.000 people watching the stream, you will still need to unicast it expensively to every single viewer from the border of the datacenter.
Can someone clear this up for me? Would multicasting work on US-Internet?
Not a bad recommendation.. one nitpick.. I would call the columns "lock" and "lock_timestamp."
I would mod you up to heaven if I could. Thanks for the wise comment!
+5 Is not enough for the value of the parent post. Optimistic Locking is the right answer in 99% of the cases
I doubt that, see below.
The issue then becomes how you want to deal with re-submitted of changes. If the entities to be saved are small and very atomic, asking the user to retype, making sure their changes are still sensible on the modified record makes sense.
In many cases (>1%) the smallest cluster of changes that still has to be in one group to make sense is anywhere from small. Entering such changes might even involve making phone-calls, looking up data someplace else, making some calculations on a sheet of paper, etc.. and so it can be time-consuming and optimistic locking is a very bad choice in such cases.
So q.e.d: Optimistic locking is not the right choice in many cases.
If your records are very large and/or very complex, then you might consider using some business knowledge to see if changes to the record can be grouped logically, and maybe even committed individually: If someone changed data for X shipment of a purchase order, while someone else changed Y, then the changes don't really have to conflict.
Sometimes the business-logic of a single object can be very complex and the data all intermangled. You can't just assume everything can be divided in small-enough independent pieces of data, just because you are too lazy to implement some sophisticated solution.
But whatever you do, build it around optimistic locking: Don't try to lock a record because somebody just has it open somewhere on a remote location. That path leads to madness.
Madness on the developer's side maybe, but optimistic locking can lead to madness on the user's side, even violence, trust me on this.
I must agree with you on one thing, though: implementing optimistic locking first thing as a basis makes sense and can save you a lot of trouble.
GUIDs (infinite)
infinite? Definitely not! Maybe not less infinite than space and time, but not infine. Damn, they're even enumerable.
after reading most of the comments I can sum it up:
Optimistic Locking: described here by many readers, easy to implement, also good idea to implement first even when using other scheme. It will piss off users from time to time, though, because they loose data. This is the choice of the (lazy) developer and/or the cheap customer.
Real row-based or even finer locking: Hard to implement right with all the timeouts, user-infos, keeping unfinished edits over sessions,.... This is the choice of the demanding user that doesn't want to loose any work at all, and the wise customer.
Realtime concurrent editing: not really sure about this.
Ramble on, guys.
on Google Books.
You are welcome
The chapter you're pointing to describes mysql table-locking as far as I can tell at a glance.
Table-locking is pretty much out of the question for the purpose here, since you would effectively prevent any editing to take place on any row within that table while some user would edit some (other) row in the table.
You're welcome.
"There would be a temp-table for every editable data-table in the db, that has the same structure plus a ID_User field. When a users starts editing a data-set, the data is copied into that temp-table."
dear lord that sucks.
Between the question, and most of these answers I can see why software is in the state it's in.
Nice solution you have there... for 1994.
I must agree with you, it's very "manual", old-school, error-prone and inefficient.
To my defense: the app was started even before 1994, back then it was using an M$-Access frontend. The temp-table stuff was invented back then to get around the effects of the optimistic locking Access was doing and also to get around the horrible performance Access was showing with larger tables.
When we migrated to the javascript frontend (still on IE6 TODAY!!!, it's horrible!) we just kept that system.
I was not suggesting this would be the way to go.
I find it interesting to be able show a solution for a web-app-related problem that was initially developed as a workaround for an unrelated problem that popped up even before webapps were in larger-scale use.
This is how we did it in an in-house AJAX app for a big corporation.
There would be a temp-table for every editable data-table in the db, that has the same structure plus a ID_User field. When a users starts editing a data-set, the data is copied into that temp-table. Other users trying to edit that data will get a view-only version of the page and info on who is editing the data. On "submit" the data is copied back to the "real" table, the lock thereby released.
Should a user decide to abandon his session, crash his browser or anything like that, he will have his unsaved edits back on next login. He will even be redirected to the edit page automatically after login, if there are pending edits.
A user can "steal" his own lock (actually session, that is) when he tries to log in with a fresh session (e.g. from another workstation at a colleague's). The old session will bail out automatically saying "session hijacked" (on any next ajax action) and the fresh session will get loaded with the old one's data.
Other users can only steal locks after a timeout (to avoid problems with people going on vacation with locked data on them)
----
This eactually worked pretty well from a user's perspective, because as opposed to with optimistic locking there would never be a situation where a user would have done some edits in vain or have extra work rechecking it.
From a developer's perspective it was a pain in the ass (maintain 2 almost identical tables, maintain checkout/checkin-code everytime).
From support's point of view, it wasn't too bad. Seldomly people would call and demand release of a lock because someone just went to have coffee and he had to edit the data real quick or managment would kill him on the spot because the data would be frozen in like 7 minutes to generate reports.
Emphasis on "in theroy" as I had an SSD go with absolutely no warning less than 48 hours after installation, but I'm filing that under bad luck.
I'd call that good luck. Bad luck would be 48 days.
the power of POKE.
from above link:
poke 1,0 Disable Operating System (Default Value 1,1)
So that's why apple had to remove that app!
yes, they make awesome harddrives
True! And my measure of being a good husband is how many affairs I DIDN'T have!
A) How do you count that?
B) Dude, even SKYNET had an IT department.
A) Dont know how to count that, but initial poster asked for both actual _and_ ideal metrics
B) Following a goal even when it's unreachable can still be fruitfull by leading you in the right direction.
True! And my measure of being a good husband is how many affairs I DIDN'T have!
A) How do you count that?
B) Dude, even SKYNET had an IT department.
A) I don't know how to count that, but the original poster asked for both actual _and_ ideal metrics
B) Following goals even when it is known that they can't be reached can still make sense and lead you the right way.
For example, for every fax successfully sent via the fax server without IT intervention, the IT department gets one point.
For every fax that needs IT intervention to be sent, the IT department loses one point.
I like this idea, because it has the side-effect of forcing managment to define in writing and exactly the services the IT-department / infrastructure is actually supposed to provide and also forces them to define some metrics and mechanism to measure this. This enables the IT-department to respond to inappropriate requests in a nicely formal way. Also the managment can prioritize on this to help IT fend off the odd jerk that thinks their particular problem is the most important in the world and should be taken care of ASAP. Such a system would also provide transparency to managment and users as to wtf these IT-jerks are doing all day and why.
I think poster has a point.
A nice metric might be the count of tickets that are never opened.
An IT-department, IMHO, should be working on making itself obsolete.
The '90s are over. Java is now one of the fastest languages around.
Around where?
Everywhere, that's the cool thing about java, you know.
http://www.system76.com/
but, mommy, there's no trackpoint!
how am I going to move the mouse without my hands leaving the keyboard? and how am I going to avoid moving the mouse by accident?
I'm pretty sure that in base-2 with no zero-padding, 100% will start with 1. :-p
also, when increasing the base towards infinity, 100% will start with 1.
Could this have any applications there?
of course: when looking to factor some number n = p * q (with p and q being primes) in order to crack some rsa key, this finding might well help in organizing (prioritizing) your search-space more efficiently and thus speed up the cracking.
In fact, this would be the universities giving up-front financing for future legal action against file sharers.
jup, just like the USA did with the taliban: give them weapons and money first to later be fucked by them.
it's like karate: use your enemy's strength against himself.
how lame to fall for that, dear universities ;)
I would...
* implement QoS sanely, give ssh, imap,... enough and the rest to p2p)
* put up a transparent proxy with a large enough cache on ports 80 and 21 (squid?)
* install adzapper to safe bandwidth from all the ads
* wait till someone complains about not getting any ads
You'd think we would... you know... communicate with our allies? Maybe?
Yeah, but as other news say, communication between french and british military is down currently thanks to conficker. Apparently they can only use fax. Maybe they have no fax-machines on their subs.
Another possible reason is that the british sub has been driving on the wrong side of the road, uhm, ocean?
So the argument is that it's reasonable to expect that my IP can be mapped to my person? Well, after this ruling it's definitely reasonable to assume this.
So this is something like a self-fullfilling prohphecy, right?
If we are voting, I vote for Castrix
-- Terry
fidex
fidelix
Open source is verifiable. Closed source is not.
Open source is verified, by many people, who discuss it in public. Closed source is not.
The OPs problem is lack of credibility with his customer, not lack of knowledge. What he therefore needs is some credible source he can use to "proove" to his customer that above holds true.