IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New That's could be really hard.
It involves setting up a locking mechanism from (nearly) top to bottom in the webapp. I looked at doing that months ago for my support app, however, mental exercises quickly showed how difficult that would be before I even got to write any code. The problem, of course, is the statelessness of web pages.

However, maybe you could do something clever with journalling. Thinking out loud here, each edit page would be given a timestamp of the data state. A subsequent post, probably 90 seconds alter, would check for any logged changes between that timestamp and now. If there are any, it would either see if it's changing what's already been changed (how good is your logging? :-) or throw back a message to the display layer with a the new state.

Wade.
"Don't give up!"
New One reason why I lean towards all-in-memory
with lazy-writing of changes.

All a particular operation need do is check the in-memory instance to make sure the operation is (still) legal. If someone tries to modify an element that has changed to disallow that modification since the first user retrieved it on their page, sending back some sort of "you can't do that and here's why" message is sufficient.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Doable from a database as well...
...just stamp read time when the page is retrieved. Then check that against a last update time when the page is submitted back.
Expand Edited by ChrisR Nov. 28, 2006, 10:31:08 AM EST
New I didn't say it wasn't doable.
The cost of that roundtrip to the database can be prohibitive under high load.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
     Programming and design experiment - (admin) - (27)
         Yes, or Icon, Wade... ;-) -NT - (admin) - (1)
             I do most of my programming in PHP these days. - (static)
         This sounds familiar. - (static) - (5)
             Re: This sounds familiar. - (admin) - (4)
                 We're back to a scalability layer. - (static) - (3)
                     You can do that with PEAR - (drewk) - (1)
                         ADODB has a reputation. - (static)
                     Re: We're back to a scalability layer. - (admin)
         A few ideas - (admin) - (6)
             How critical is update ordering? - (drewk) - (5)
                 Critical. - (admin) - (4)
                     That's could be really hard. - (static) - (3)
                         One reason why I lean towards all-in-memory - (admin) - (2)
                             Doable from a database as well... - (ChrisR) - (1)
                                 I didn't say it wasn't doable. - (admin)
         Consistency, Availability, Reliability - (tuberculosis) - (4)
             Define your terms. - (admin) - (3)
                 mmm kay - (tuberculosis) - (2)
                     That's what I thought, for the most part. - (admin)
                     Or how about we do this: - (admin)
         Have you looked at the O'Reilly database war stories? - (tonytib) - (4)
             Yes, I've seen those before. - (admin) - (3)
                 I'm really starting to think there's something to my idea - (drewk) - (2)
                     Isn't that what SQLite is sorta trying to solve? - (static) - (1)
                         It's a solution to a specific problem - (drewk)
         XBase, of course. - (pwhysall) - (1)
             I heard that -NT - (tablizer)

I knew it as soon as you told me.
89 ms