Re: Transactions: good or bad?

> I have no problem with your example. It is one issue with one kind of
> implementation. It just has little to do with my logical argument.

Does it? I'm arguing that any implementation of multiple concurrent assignments in order demands a transaction in a serialized view in order to achieve data consistency. I claim that this because any implementation of any assignment of an array SRC to an array DST must obey serialization theory in order to achieve a serialized view. I may be wrong, but it seems that UPDATE even at a relational theory level demands the assignment of multiple variables. The SALARY example is one, and, a hypothetical update of multiple tables for inventory is another.

If you could show me at a higher level example how such problems would be made, and, could then argue how the implementation need not have transactions, then you've struck gold, or better still, palladium.

> I did not particually follow you there. My FP knowledge is limited.

It was late when I typed it. My FP knowledge is limited as well. I do know that the essence of Functional Programming is that there are no "assignments". If you look at any statement A = B, then, A = B can only be executed atomically on most hardware. If B has multiple values and A has multiple values, access must be controlled to A and B for the assignment to be consistent.

FP gets around that requirement because B is never copied to A, only a rule set for A is modified. So, inherently you avoid deadlocks because you never have a reason where A is waiting on B and vice versa, in the multiple transaction case. I think you could lock ahead all A,B in a transaction, build up private rules lists, and then, drop those rules in on commit, and the views would be serialized. Such an application would require a formal proof of its model.

> However
> you are arguing from a low level problem example,

True, but, sometimes, you have to be able to specify that you have air of a certain density in order to design a wing.

> so I can't see how your
> comment below is possibly justified.

Fair enough. It is a sweeping statement.

> By "the predicate problem" do you mean predicate locking?

The where clause thing. Like, if you say UPDATE a SET a.i = 42 WHERE a.k = 'todd', then, you don't need to really go out and write a bunch of values to a table. You could simple add a.k (todd ) -> a.i = 42 to a global set of rules. This could be much faster and would definately be more concurrent. SELECT would be a b--- to implement though.

> I would agree that there is probably quite a bit of mileage in bridging the FP
> and relational approaches to things.

What that bridge looks like, I do not know. But the investigation is certainly worth investing in an FP book, I would think. I'm going to.

> It's not just the where clause, you need to check overlaps on the complete
> subset of the database that is referenced in a update/query.

Agreed.

>
> Why are multiple indexes a problem?

Actually, I'm wrong here. If you have a pure FP database then you probably would not need indeces in the traditional sense at all.

>
> R U thinking of a variation of the problem that occurred on a Halloween back
> in the day?
> http://www.computer.org/annals/an2002/pdf/a2086.pdf

Not for that, but the halloween problem is actually a good example of why a transaction would be needed. Can you show me how the halloween problem in your logical model would not require an internal transaction to implement?

>
> From my naive perspective I can't see why predicate locking should be all that
> difficult.

I worry as the proof will be tedious to construct and I haven't thought through it yet.

> Yes, but they don't do a very good job of looking like they execute all at
> once if a user can hum and ar for a few minutes while deciding to commit or
> roll one back. They certainly don't look like they execute all at once if
> another users can't see any values of the database from the time a txn starts
> to the time it commits.

I agree with this completely. As a consequence you can't use transactional systems for systems with hard real time performance bounds. By design they must fail those bounds.

> You must serialise, but there are many ways of doing it.

Agreed, but your choices narrow radically as soon as you implement assignment of multiple items.

> Indeed and that is why I suggest the database provides for a 'wait upon
> condition' to keep business deadlock detection within the DBMS.

But that implies a continous connection, no? Would it not be better to have the database have a notification of an event, that hands you a "next step" token that is the only way that you can do something else next?

> Nope
> Yep.
>
> ;-)

Green eggs and ham. :-) What was the doctor suess about the two guys stairing at each other forever because neither would move sideways? Received on Tue May 20 2003 - 23:29:31 CEST