AJAX & Record Locking 4

Dr. Dobb's Journal has an article in the current print edition titled AJAX & Record Locking.

This is a quite readable article on a use for AJAX that helps solve a real problem in web-based applications. I know that solving this is among the top issues for my customers as they take applications to the web.

Code presented in the article is available for download.

Tom Morrison

http://www.liant.com

 

[tsdragon]

Thanks for the reference!


Tracy Dryden

Meddle not in the affairs of dragons,
For you are crunchy, and good with mustard.

 

[1DMF]

A simple solution, holding a table of record id's that are locked and by who, however how do you detect when the editor leaves the page, if the person holding the lock, decides to just close their browser, what removes the record lock? I couldn't see where this was addressed.

onunload is unreliable especially with todays popup blockers, any help with this bit is appreciated.



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[k5tm]

Check the section of the article titled Server-Side Components.

If the server is expecting a 'heartbeat' from the client (upon which this whole record-locking scheme is based), then, assuming the heartbeat is maintained even when the record is locked, the server may deduce certain things from the lack of a heartbeat, viz the client has gone away, and release the lock.

That is the reason for the two status values owned and noSession. The server returns owned to the request made while the record is locked by that specific client. noSession would be returned if the server decided for whatever reason to release the lock, such as a timeout caused by the client navigating away from the page, and then navigating back to it.

Tom Morrison

http://www.liant.com

 

[1DMF]

thanks for the reply, I was concluding that would have to be the method employed to acheive this, just didn't see it mentioned, that'll teach me for only half reading the post and skipping sections

what sort of load do 'heartbeats' place on a server?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[k5tm]

I would think that should depend on the particulars of the application, even the specific business object that is being modified under lock.

Clearly the message frequency while waiting for a record to unlock might be once, twice or more a minute, while the message frequency while the record is locked might go down to once every two or three minutes.

That would allow short duration modifications (e.g. correcting an email address on a customer record in a CRM) to operate without ever sending a heartbeat while the record is locked.

However, a customer service agent doing a followup on a customer complaint may have a complaint record locked for an hour while on the phone, so the heartbeat every two or three minutes should keep the server happy.

Tom Morrison

http://www.liant.com

 

[1DMF]

I guess it's down to the number of clients trying to access a locked record and length of time the record is locked for.

you might also have to code some type of queing system, so the order people are waiting is the order the edit option becomes available, then how long do you give them the availability until you release.

If someone gets fed up of waiting and goes to the loo or makes a cuppa, they might miss their turn or not notice the edit option is now available to them and get placed on the bottom of the queue, then people were waiting around for nothing!

lol - the process in principle is always easier than reality!

I do actualy use the 'heartbeat' method for our members area, it's a way of checking they are logged in and keeping the DB up-to-date.

If the server doesn't receive 'heartbeat' within ten minutes it logs them out, the 'heartbeat' is triggered every 3 minutes. - so far it seems to work fine, no-one has complained of any problems anyway

1DMF

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[k5tm]

The edit button gets enabled when it is discovered that the record is unlocked. The lock is not asserted, however, until that edit button is clicked and the lock function returns success. So, while someone is off to the loo the edit button may enable and disable several times as the desired record (and it must really be a desirable record!) is unlocked and locked.

Tom Morrison

http://www.liant.com

 

[skiflyer]

Careful assuming the client has javascript enabled in such a way to allow everything to work nicely... I occasionally disable my javascript completely for various reasons and would hate to get kicked from a page with no explanation for doing so.

 

[1DMF]

If you aint got JS enabled, you can't use AJAX websites.

What would the AJAX forum suggest as the best way of telling its users to enable/leave JS enabled.

<noscript>This site uses AJAX, please enable JavaScript and reload the page!</noscript>

OR

<noscript>Either you have turned JavaScript off for no apparent reason or your browser is rubbish, please get the hell off my website!</noscript>

...................................
JOKE!!!! before anyone takes it seriously!

but this is an important issue, AJAX require JS, what is the best way to get the user to enable JS, surely you don't write 2 sites one that uses AJAX and one that doesn't?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[skiflyer]

Personally I write one site which works fine without JS, then I add functionallity using javascript... "graceful javascript failure" is how we've always referred to it.

 

[k5tm]

Careful assuming the client has javascript enabled in such a way to allow everything to work nicely

While this is true for the general public, many in-house applications are having their user interface recast using web technologies. In such a situation, this is not an issue.

Tom Morrison

http://www.liant.com

 

[skiflyer]

Very good point... and for sufficiently complex apps I think 1DMF's warning is plenty, sometimes you can't fail down gracefully and you just need to tell the user they can't access this site from their Mobile phone or Lynx terminal

 

[skiflyer]

Oh, and 1DMF, I know it was a joke, and I couldn't care less... but just for the record one of the main reason folks like me turn of JS on occassion is to test ADA compliance with screen readers and the like.

You can ask Target if that's a good thing to do or not, I think they just paid out a few million for not doing it.

Anyway, like I said, doesn't ruffle my feathers at all but may want to consider it with certain apps.

 

[1DMF]

screen readers, handhelds, mobile phones, portable devices etc.., this is not something I have really given much thought of or have any experience with, so don't tend to concider them when I develop, my target audience is someone with either a laptop or desktop, windows and I.E. or FireFox, so have not had to concern myself of late with compatibility on lesser devices.

I guess with Mobile phones , the situation will change, but I'm of the opinion that ALL websites shouldn't have to be Mobile phone concious, and pesonally I won't be using my phone to surf the web until they are capable of rendering on a special eye device which gives me a full screen effect, voice recognition so I don't have to use a stupidly small keyboard, not incur massive charges for the privalige and capable of running the latest web browsers.

Me & the Missus I guess are of the few who hate mobile phones, don't use them and only have one in the glove compartment of the car incase we break down, especially because there are bugger all public phones in the world!

But I do understand where your comming from!





"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.

 

[skiflyer]

Here's your full screen display for a phone...

http://www.thinkgeek.com/electronics/video/88e0/

Order me one while you're at it please, I'll pay you back in beer, slowly.

I know we're way off topic, so two points to bring it back to the original post...

1) I think this is a great use of AJAX, database locking is a tricky beast and can cause lots of problems when used incorrectly, but when used properly it's a godsend, and adding it to true web applications is great.

2) IMO The dead-man's switch part of it is the real boon... even if it's not record locking, this has all sorts of potential benefits in terms of what to do when a user exits in the middle of a process (thinking of abandoned shopping carts, or other 5 step processes that get left off at step 3... do you ever want to auto-save this stuff, or maybe auto-erase it rather than let it clutter up a database)

 

[1DMF]

lol - great link , though you might find it hard walking at the same time!

I prefer the special glasses concept I saw on tommorows world a few years back, but i don't think there is enough beer in the world to pay for them yet!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you.