Re: Transactions: good or bad?

"Todd Bandrowsky" <anakin_at_unitedsoftworks.com> wrote in message news:af3d9224.0305191852.443b80c_at_posting.google.com...
> > This depends of course on how the implementation decides to serialise
things.
>
> If you want to have a logically consistent view of time, then, the
> implementation must implement some form of serialization.

I've not been disagreeing.

> Assume you have two concurrent overlapping statements:
>
[details snipped]

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.

> There is a way to avoid this, but it's not what you are talking about.
> foo = bar can be a functional declaration rather than an assignment.
> foo would be an accumulation of formulae based on bar, and vice versa,
> and I believe that those would run concurrently much more efficiently.
> So, foo = bar would not be a copy operation, it would be an addition
> of a functional specifications to the list of such specifications in
> foo. When foo is ultimately selected from, (on the right hand side),
> elements in foo that are based on bar would be calculated at select
> time. Off the top of my head I cannot think of anything in the UPDATE
> statement that would require a lock on the right hand side, if all the
> UPDATE did was add a functional relationship to the target.
>
> Such a scheme could certainly haul ass, but there are some serious
> theoretical problems that must be addressed. The one biggy that I see
> is that there will need to be some continous factoring of facts
> presented via the update to keep the search side down. That is, if I
> update Name = Todd and then Name = Bob, then, somehow I have to
> collapse the functional specification Name = Todd and Name = Bob into
> a single state. I do not know if every combination of expression is
> ultimately factorable. Are there prime predicate expressions?
> Intuitively I think this answer must be yes, there are. So these
> states are definately going to pile up.

I did not particually follow you there. My FP knowledge is limited. However you are arguing from a low level problem example, so I can't see how your comment below is possibly justified.

> Still, I think functional programming seems to offer the only real
> hope of avoiding many of the woes of serialization.

> I would say that
> the founders of SQL probably realized that real relational algrebra is
> essentially functional programming in nature, but, because they bailed
> on the predicate problem, they had to make do with simple assignment.

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

> A relational database built on top of a functional programming
> approach might actually be the ticket we are all looking for. After I
> finish Commodity Server, I will probably implement this as an
> experiment.

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

> > If you do true serialisation - only one update running at any one time,
>
> True, but that is impractical for most applications.
>
> > then
> > unless you have user transactions in the equation you won't get deadlocks.
>
> True, but a serialized database has less of a need for transactions.
>
> > A
> > more efficient serialisation would be to not only allow two 'overlapping'
> > updates to run simultaneously.
>
>
> See above. Isn't this the predicate based locking that we discussed
> earlier? Essentially, you want to lock on a where clause. This runs
> into some problems when multiple indeces are considered.

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.

Why are multiple indexes a problem?

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

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

> > The database is a single value. A non-scalar value consisting of relation
> > values (that consist of tuple values that consist of scalar values).
> >
> > > atomic assignment of multiple
> > > values is exactly what a transaction is
> >
> > Most people's idea of a transaction is of something that is not atomic
over
> > time.
>
> Everything about transactions is ACID - Atomic, Consistent, Isolated
> and Durable. The point of the whole thing is that a transaction is a
> set of statements that look like they execute all at once.

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.

> >
> > If your idea of a transaction is an atomic-in-logical-time change to
multiple
> > values within the non-scalar database value then your statement holds.
>
> It is.
>
> >
> > Possibly, depending on the internal implementation code.
>
> No, you must. It is serialization theory, AFAIK.

You must serialise, but there are many ways of doing it. .
> > It might seem silly, but it is infact a benefit because it is an example
of
> > independence. Your users are not dependent on internal deadlock detection
> > schemes for their logical problem of deadlocks. The implementation can
freely
> > alter, tweak, tune or discard their deadlock detection schemes
independently
> > of any user visible scheme.
>
> It can be useful to allow a checkin / checkout model of a selection, I
> do agree. However, deadlock detection is hard and not many people
> are good at it. How many Java programs are that hang for no reason
> because everyone randomly throws locks around without really doing a
> dependency analysis?

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

> >
> > Your argument is one that goes directly against the principle of data
> > independence.
>
> Nope.

Yep.

;-)

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Tue May 20 2003 - 19:09:34 CEST