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
>
Received on Thu Oct 22 1998 - 00:00:00 CDT