Re: Optimistic Concurrency Question:

> How do you guys manage conflict resolution w/ optimistic concurrency? <,

Look at Interbase from Borland for one model. The for papers by Jim Grey on this subject. The basic idea is that conflict is rare and that you should not build a system to treat it as the norm. The advantages are pretty strong. Interbase can query, update and insert to the same table without any measurable loss of speed.

>> I am thinking of a "Conflict Detected" form containing conflicting
data the user can save or write down, followed by an automatic reset of the data to the state of the most-recently-saved record [sic]. <<

Actually, you want to roll back the whole transaction, not just the row where failure occurred. I like the explicit resolution, but is that your business rule? Are some data sources more trusted than others? Do you inform both conflicting users? One conflicting user? A third party?

>> Is there a smarter way? <<

Univac was experimenting with logical concurrency control several years ago. the idea was that only transactions that did not overlap would be allowed into the database at the same time. A special engine would parse the predicates to determine which jobs in the queue would be allowed to play together, and a scheduler would see that everyone got a turn at bat (we have scheduling down pretty good from the days of batch processing). No need for locks or for conflict resolution! The engine could be pretty portable, too, since it works with source code or a parse tree.

I don't think it every became a product. Received on Sun Oct 20 2002 - 20:30:09 CEST