Hi Rene and Christian,
On Sun, 13 Jan 2002 09:15:17 +0000
Rene Brun <Rene.Brun@cern.ch> wrote
concerning "Re: [ROOT] TFolder or TDirectory?":
> Hi Christian,
>
> Christian Holm Christensen wrote:
> >
> > How's that gonna help? One transaction A, write top;1, but while it's
> > executing another transaction B, comes along and writes top;2. Now A
> > and B finished, and transaction C comes along. Now which one of top;1
> > and top;2 should be used? Should the server merge the two tops or
> > what? I'm asking 'cause I'm curious, and I don't know how I would go
> > about implementing transactions in ROOT.
> >
>
> I have never advocated this solution as a general solution. The
> solution with writing to a different file always work anyhow. In the
> Christian's case, the update frequency is so low and likely under
> his control that he can assume that two writers do not write to the
> file (if he has this control).
Ok. That obviously simplifies things alot. However, it also means
that transactions are not that important in that case. If you always
know that you have one writer/reader, then you can simply do locks.
However, if you have one writer (or even multiple writers) and
multiple readers, each client need to have his/hers own copy of the DB
at the time of his/hers transaction starts, to look at - otherwise you
may not have referential intergrety. I was wondering how the solution
of different keys would help do that.
> > > The time for one transaction should be below 1 second.
> >
> > Uh, what it transactions take longer than that? Suppose you want a
> > transaction to lasts as long as it takes to write 1G Alice events to
> > disk (not via the transaction though, but the transaction is logging
> > it)?
>
> This seems obvious and does not deserve a long speech. That is why
> we are advocating the combined use of ROOT with a RDBMs systems when
> transactions are required for a run/file catalog for example.
It needn't only be because you need transactions. Perhaps what you
need is something really lightweight and SQL capabilities.
> > However, the transaction protocol is really essential if ROOT is to be
> > a (distributed) database system on a very large scale.
This statement was mearly an observation, not a postulate. Sorry if I
didn't make that clear enough.
> I repeat. This could indeed be implemented in ROOT. We do not see
> any reasons to rush in this direction since simple tools like mySQL
> (or equivalent) are there. Implementing transactions can be done
> with a separate transaction server.
Perhaps Christians code is a good starting point (probably is).
Perhaps he'll like to continue along that path (transaction file
server).
> > Oh, one thing. How would you handle partial fills of a tree. Suppose
> > you have a TTree with branch A and B, but you only want to update
> > branch A, and not make a new entry in branch B? At fill time it may
> > not be that bad, but at read time, you may get into trouble if the
> > default CTOR does some wierd stuff, like setting members to
> > non-invalid (that is valid) values, so that the entry looks like it's
> > good, while it's really empty. I remember I had a problem like this
> > some time ago (a long time ago in fact) when I was looking at the
> > possiblity of using ROOT as the database backend of the BRAHMS run and
> > conditions catalog. It may have been fixed somehow after that.
> >
>
> We had several iterations on this point last fall. We want to discourage
> updating branches of a tree. An alternative with Tree friends
exists.
I didn't mean doing TBranch::Fill. No, what I mean was, if you have a
TTree like
A* a = 0;
B* b = 0;
TTree* tree = new TTree("T", "A Tree");
tree->Branch("A", "A", &a);
tree->Branch("B", "B", &b);
and then for a given instance only want to fill a, that is, b = 0:
// Fill number n
a = new A;
b = 0;
tree->Fill();
What happens when you read back that entry? Supposing that you do
A* a = 0;
B* b = 0;
TTree* tree = (TTree*)gDirectory->Get("T");
tree->SetBranchAddress("A", &a);
tree->SetBranchAddress("B", &b);
...
tree->GetEntry(n);
Will b == 0? Or will it be created according to the default CTOR?
What if objects of class A or B is put in a TClonesArray that is
stored on a branch, and you do TClonesArray::Clear() to limit the
numbers of new/delete mesages? This is what I meant!
Another question: Is it possible to have a TRef member pointing to
another object in a different entry? Since the TRef does not work by
address, I guess it can.
> > To this end, it would be nice to have some sort of SQL search
> > functions in TTree. I believe it's doable. What is needed is an SQL
> > parser and a translator from SQL to the regular ROOT selection
> > mechanism.
> >
>
> Not a very efficient way to make a query to a Tree. We already have
> TTreeResult, TTreeRow, TTree::Query. Anything beyond that is likely to be
> application dependent and can be coded with a few lines of code.
Well, it may not be efficent, but it makes it easier to have ROOT drop
in as the database backend. The idea is simply that you should be
able to have
TSQLServer* serv =
TSQLServer::Connect("url", "db", "user", "passwd");
TSQLResult* res = serv->Query("SELECT * FROM Runs WHERE runno=1234");
The idea then that if "url" is of the form "root://host/dir/file", then a
connection (via rootd) to the TTree "db" in the file "dir/file" is
setup, but it could also be "mysql://host" or what ever. That would
really make it flexible. And who cares if it takes 1 ms or 2 ms to
query for information on a run, if that's something you do once or
twice per job.
Just my two pennies worth.
Yours,
Christian Holm Christensen -------------------------------------------
Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91
DK-2200 Copenhagen N Cell: (+45) 28 82 16 23
Denmark Office: (+45) 353 25 305
Email: cholm@nbi.dk Web: www.nbi.dk/~cholm
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:50:38 MET