• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint

17.3. Concurrency

When multiple computers must work together at the same time, all sorts of interference problems can arise. Shared object updates are a simple example. Unless an application is designed carefully, there is always the danger that one client will overwrite another client's data in a shared object. While there is a slot-level locking mechanism, there is no intrinsic mechanism for locking shared object slots for a controlled period of time.

In the database field, interference problems are well understood and often easily dealt with using the database's ability to lock records, maintain a multiversion consistency model, and to commit or roll back transactions. In real-time multiuser applications, the tools available to deal with interference problems are often not quite so advanced. Consequently, FlashCom developers need to be aware of the potential for problems and how to deal with them. Unfortunately, the subject of concurrency is a large one and cannot be covered in detail here. A good reference is the chapter on concurrency in recent editions of C. J. Date's book An Introduction to Database Systems (Addison Wesley). This section reviews a number of problems you may run into when developing FlashCom-enabled applications and some common ways to deal with them.


PREVIEW

                                                                          

Not a subscriber?

Start A Free Trial


  
  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint