Re: Transactions: good or bad?

"Todd Bandrowsky" <anakin_at_unitedsoftworks.com> wrote in message news:af3d9224.0305201329.6c234364_at_posting.google.com...
> > 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.

"multiple concurrent assignments" is a physical concept not a logical one. Logically all assignments are serialized. If in your implementation of serialization you want to have multiple concurrent and potentually overlapping assignments, then yes transactions of some nature might well come in handy.

> 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.

Again I've never said that transactions are not useful for implementation issues.

> I may be wrong, but it seems that UPDATE even at a relational theory
> level demands the assignment of multiple variables.

There is only one variable, the database variable. Other so called variables, such as relation variables, are just subsets of the database variable.

> 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 think you do just that below

[snip]
>
> > 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.

OK, that one. Does anyone know if this is a well known technique? I doubt that it is a truly novel idea.

> > 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?

Well if you must use indexes, then you need to deal with such problems. I believe one can do interesting things if you build a DBMS without them. But again, I'm not against transactions internally.

> >
> > 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.

So logical transactions limit the class of applications that a database can support? I agree.

> > 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?

'wait upon condition and return control' would imply a continous connection.

'wait upon condition, then do update X' would not imply a continous connection, but would need to be clear who was doing update X - the user or an agent for the user...

'wait upon condition then send message'
'wait upon condition then send authorisation to allow further database interaction '
are both interesting ideas. Thanks.

> > 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?

Pass

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Wed May 21 2003 - 17:38:45 CEST