Re: Transactions: good or bad?

> So you hope, but those are the same people he is trying to educate.

And he hopes to do this by insulting them? I may be ignorant about a lot, but I did at least take the plunge and write a database server, and, it's pretty handy for its domain space. It seems to me that if this stuff is so important, then, if I am going to be called ignorant, then, at least throw some URLs my way.

> A proof, an axiomatized derivation of fact, where the derived fact is 100%
> certainty of correct outcome. Contrast this with a random hodge-podge of
> inputs for which one has verified outcome.

Um, imagine if you will you had a technology that could lift out all of your decision logic, and drop it into a tree. Given that, and a call graph, you could back generate test cases to ensure 100% complete coverage. If, each one of those cases yields correct behavior, is not the program formally proved? You could also explode out expressions and look for asymptotes, local minima, maxima, etc, and do test cases on either side of those?

I'm not saying that dropping random data onto an application is a formal proof. I'm saying that an application contains the information with which a complete coverage of test cases could be theoretically constructed, and, if you had that construction, you could then pair that up with a database of previously proved results and thus validate your application.

>
> > Turing PROVED they are all the same.
>
> Really? Would you care to point us to this alleged proof?

Is there not a proof that says that any language that can implement a turing machine can in effect implement any language?

>
> It is as good as any other strategic weapon of which the general population
> have profound ignorance.

It is a language and a powerful one. But, I don't think that because it is a powerful language you should worship it above other languages.  Even mathematics itself is not a single language anyway. There are related constructs but there are plenty of ad hoc rules within it.

> One cannot provide better performance than the best performance. You are
> simply making an unfounded claim.

Quite true. Then, in that case here is a brief sketch of what I do. I will provide a more formal argument when I am not at work!

I have each profile as a skip list key of a start time, a stop time and a value. It's basically an index of ranges. The skip lists work pretty well and were a lot more convenient than btrees. the one thing that I do differently from PUGH90 is that instead of storing the level of the list I calculate it based upon the number of items in the header because I have to write lock the header less frequently.

Each profile gets dropped into a big memory mapped file. Underneath it all I have a little set of primitives that do things like set a range of time in the profile to a specific value. So, I can set, internally, set profile xyz from tuesday to wednesday to the value of 42.

On top of all of that I have an engine for doing math with profiles. It is the usual two profile plus an operator into a destination profile construct. For now, intermediate results are stored into the database itself. I have it in mind to cache based on subexpression in a future release. I also have some extraction operations. Like, I can get profiles by any combination of date and time.

All of this is driven by a virtual machine that more or less maps internal engine method calls into instructions. I have a combine_profile instruction, etc. On the client side a compiler generates this code and ships it to the server over a socket.

The whole reason that I became so interested in transactions is because the usual locking mechanisms do not work well for my application. It is a requirement to be able to let a lot of users do concurrent updates and queries. I originally married transaction support to the memory mapped architecture. So, if I mapped a read ptr or mapped a write ptr, I would add a read / write lock to the transaction. Unfortunately for a variety of theoretical reasons that I bumbled into, I discovered that this approach was flawed. I could either choose to apply blocking write locking, and deal with the possibility of deadlocks, and, worse, locking for the entire life of a transaction, which blows. Or, I could do MVCC, which, even if I could get it to work, would, at best leave me with having to rollback downstream transactions, which, in a time critical application, completely blows chunks.

Also, during this time I was arguing with Paul from IBM Global Services about Arrow of Time and I finally understood that he was describing the very problem that I was having. After disagreeing with him at first, I came to realize that the problem I was having was having transactions to begin with, and, while at first his idea of moving locks out of the database seemed absurd, suddenly, it makes perfect sense. Then I had the aha moment and I realized that if I locked on virtual machine instructions, I could still have a course grained concurrency, that I could make more concurrent as time went forward, and, then, having a user lock would work really well for me because my connection is only alive long enough for the client to send compiled code to the server and get a result back... so a user could forget to unlock something and I could theoretically do that for them on disconnect.

Then I realized that Paul's comments about not needing transactions at all were completely correct, and I wrote the email about eating crow. But then I got excited about the result and plugged it not so much as because I wanted to brag or anything - the link is not even on my web site! But because I was excited about the result!

>
>
> > Feature: a language easier to use for commodities
>
> Really? It is easier to use something other than mathematics for
> commodities?!? What attributes of mathematics make it unusable for
> commodities?

Uh, I think we miscommunicated here. Maybe I did. If so, am sorry!

> In fact,
> these companies find it more convenient to encourage the ignorance.

I have no argument with you there.

> Logical identity.

??

>Physical independence.

??

>Logical independence.

??

> well-founded robust user-defined type system.

OODBMS do this already? Received on Tue Jun 10 2003 - 20:20:56 CEST