Results 1 to 10 of 10
  1. #1
    Join Date
    Feb 2005
    Location
    Cape Town, South Africa
    Posts
    57

    Arrow Notifying client of record update?

    Hi,

    Example:

    Multi-user client/server environment. User #1 requests record X. Shortly afterwards, user #2 requests the same record. Both users now have the same data displayed. User #1 then makes changes to record X and commits them. User #2 is still seeing the old version of the record. Is it possible to somehow notify user #2's client application, so that it can update its display?

    This is not so much to prevent lost updates (I could use other forms of concurrency control for this [as I've learned about tonight]), but more as a means of keeping the display of data accurate (up-to-date), so that users acting on such data would not be misled.

    Are there any frameworks which handle similar situations?

    Any ideas, thoughts, suggestions, . . . ?

    Thanks,

    _da.

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    This should be handled by record locking, which varies from one server technology to the next.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  3. #3
    Join Date
    Feb 2005
    Location
    Cape Town, South Africa
    Posts
    57
    Hi blindman,

    Like I said, it's not a question of handling problems with concurrency, but rather in keeping the display of data consistent with the database.

    The only thing I can think of is to manually refresh (re-request) the record after a certain period of time has elapsed, but it would be nice if I could be pushed updates, rather than having to pull them.

    Thanks,

    _da.

  4. #4
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by darkangel
    This is not so much to prevent lost updates (I could use other forms of concurrency control for this [as I've learned about tonight]), but more as a means of keeping the display of data accurate (up-to-date), so that users acting on such data would not be misled.
    IMHO, have a triggered procedure on the table send a request to a background task running on the same machine as the DBMS. The background task then spools the notifications out to the clients. This would be the best way to handle things if you were doing one of those fancy AJAX web interfaces.

  5. #5
    Join Date
    Feb 2005
    Location
    Cape Town, South Africa
    Posts
    57
    Hi sco08y,

    That's what I was thinking.

    Someone else suggested having the clients message one another after they've successfully updated a record. That could also work, I guess.

    Thanks,

    _da.

  6. #6
    Join Date
    Jun 2004
    Location
    Arizona, USA
    Posts
    1,848
    Yes, but having the server broadcast a message when the tablle is updated provides central control of the messaging transmission process, and you don't have N copies of the message send floating around. IMO, it's just cleaner to keep the clients as simple as possible.
    Lou
    使大吃一惊
    "Lisa, in this house, we obey the laws of thermodynamics!" - Homer Simpson
    "I have my standards. They may be low, but I have them!" - Bette Middler
    "It's a book about a Spanish guy named Manual. You should read it." - Dilbert


  7. #7
    Join Date
    Feb 2005
    Location
    Cape Town, South Africa
    Posts
    57
    Hi loquin,

    I also like the idea of central control, as well as a simpler client. However, I don't quite understand how the number of messages would be decreased?

    Thanks,

    _da.

  8. #8
    Join Date
    Oct 2002
    Location
    Baghdad, Iraq
    Posts
    697
    Quote Originally Posted by darkangel
    Someone else suggested having the clients message one another after they've successfully updated a record. That could also work, I guess.
    I'm doubtful of that for two main reasons: a. you have to send additional traffic to determine whether the clients are able to see each other on the network b. the client now has to know more about the schema.

  9. #9
    Join Date
    Jun 2004
    Location
    Arizona, USA
    Posts
    1,848
    Quote Originally Posted by darkangel
    Hi loquin,

    I also like the idea of central control, as well as a simpler client. However, I don't quite understand how the number of messages would be decreased?

    Thanks,

    _da.
    I wasn't talking about the messages, I was referring to the message send code. There would only be one instance of the broadcast code, not many.

    If you use a message broadcast, (UDP) there wouldn't be any more messages - it's just that you have a more difficult time managing code that is widely deployed.
    Lou
    使大吃一惊
    "Lisa, in this house, we obey the laws of thermodynamics!" - Homer Simpson
    "I have my standards. They may be low, but I have them!" - Bette Middler
    "It's a book about a Spanish guy named Manual. You should read it." - Dilbert


  10. #10
    Join Date
    Feb 2005
    Location
    Cape Town, South Africa
    Posts
    57
    I see what you mean — I misunderstood.

    Thanks,

    _da.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •