Re: Best database for web backend on Linux?

we're still talking at cross purposes here. if we're using "browse-mode" as the starting point .... The Optimistic Locking is: t1. Read t2. Re-Read with Lock t3. Update t4. Commit / Rollback You lock once you know the user wants to modify that record, not just when they are viewing it. In Sybase you would: t1. Read t2. Update t3. Re-Read with Lock t4. Commit/Rollback Which has a very different look and feel to the user, and in most Oracle tools those steps are done for you. In Sybase you code it yourself. Thor HW >If the updates are independent of the prior state of the data, what >you describe will work. However, if the updates are dependent upon >the state of the data prior to the update (which is the more common >case in my experience), then the lock must take place at READ time. > >That's why READ locks exist (and the other case is why lower levels >of "isolation" (or serializability) exist). > >For example, if your intention is to increment a value by one, >you must > > t1: READ value > t3: WRITE new value > t4: cleanup (including releasing the lock) > >If a lock is established only at t3, you've a loss of serializability. >Consider a second process: > > t2: READ value > t5: WRITE new value > t6: cleanup >