WebSocket technology has been included in all the major
browsers and several server side applications have been developed to support
WebSockets. Some of the server side
solutions we have looked at are:
- http://xsockets.net/ for .NET.
- http://autobahn.ws/ for Python
- http://socket.io/ for node.js.
Name a popular language and I'll
bet you someone has created or is creating a WebSocket Server application with
it.
But this post is not about what WebSockets are or how to
develop them. There are several postings
on the web that cover them far better than I can. If you need to understand
more about WebSockets, I would recommend starting at http://www.websocket.org
for more information..
What I'd like to talk about is what problems WebSockets can
solve for us. We have several requirements for our application that we are
exploring the use of WebSockets. Here are a few (but not all) that we are
looking at:
- Record
locking
- Real
time scheduling/status updates
- Build
in Instant Messaging (IM)
- Administration
functions (ie: seeing active users, system shutdown notification, etc.)
- And
more....
Each one of these topics is a blog post in itself. I've decided to narrow it down to one “Record
locking;” look for posts about others in the future.
One of the major challenges in creating multi-user web
applications is managing concurrent access to a data record for updates. Because HTTP is stateless, the challenge is
to develop a way to prevent and handle change conflicts. I've seen several
solutions developed and used in the past.
Record lock bit:
This solution entails creating a bit column in the table to
flag a record as locked. When a user is
about to edit a record, the record is updated with a lock bit that would
prevent others from editing the same record.
This requires the browser to make a request to the server to update the
record. When another user tries to edit
the record, it would first check to see if the lock bit is set. If it is, the
user would not be allowed to edit the record.
The challenge with this solution is that the user does not have any real
time notification when the record is unlocked. The browser would have to
constantly poll to see when the record is free.
Additionally if the user’s (the one editing the record) computer crashes
the lock bit could be left in a lock state. This would prevent anyone from
editing the record until the lock bit is cleared. Both of these challenges can be solved but it
would take some complex coding.
Versioning:
Another solution is to put a version number with each
record. When the user views a record,
the records version number would be retrieved with the record. When user edits the records and saves, the
server side code would first verify that the record has the same version number;
if it does the user is free to save the record.
If the version number is different, the server would prevent the save
and would notify the user that the record was updated by someone else. At this time, the challenge is what to do
with the unsaved data. Some solutions would be:
- Code
the application to try to merge the changes
- Just
have the user discard their changes and re-enter them
These options would require a good chunk of coding or an angry
user.
WebSockets:
With WebSockets, we are looking to have the client be
notified in real time that some else is editing the record. When a user wants to edit a record, a
notification is sent out to any client that is viewing the same record. At that point the other users would not be
able to put the record into “edit” mode. The edit button would disabled and a
message would be displayed like “User John Doe is currently editing”. When the record is saveed or editing canceled,
a notification would go out to the any user viewing the record. This notification would trigger the edit
button to be enabled on the other clients. It would also send updated record
data to the display. Each user viewing the record would see the updates in
real-time.
We are currently in the prototyping phase of this solution
and as we learn more I will post about our findings (what worked, what didn't,
etc)
Wish us luck.
No comments:
Post a Comment