Hey,
>>What is a Berkeley transaction?
>>
>>A transaction is effectively a private copy of the entire database.
>>
>>
>>
>No it's not. A transaction is _not_ invisible to other users of the
>database, even when not committed. Nobody outside the transaction sees
>the changes until they're committed, but everybody sees the locks that
>the transaction creates -- and the transaction sees other people's locks.
>
>
This is implementation dependent. In a multi-versioning scheme like
used in Oracle and MySQL InnoDB tables, what Karl said is more true than
not true.
He did use the word effectively not invisible:-)
>
>
>>I'm not saying it wouldn't be more efficient to have our own locking
>>scheme. It probably would.
>>
>>
>>
>It would be a _lot_ more efficient. Every time you create a transaction,
>you end up writing to the log files. And every time you commit it, you
>have to sync the logs. That's a _lot_ of fsyncs, and they're slowing us
>down tremendously. What's worse, we're writing and sync'ing logs even
>for read-only operations that don't change a single bit in the database.
>
>
>>
>>
>However hard they work on making transactions efficient, they can't
>avoid the fsyncs. In case you're wondering if those fsyncs are really
>that bad, hear this: I hardcoded a DB_NOSYNC when opening the database
>in fs.c -- and reduced "make check" time on Windows by *half*. Of
>course, we can't do that for a production repository, but it makes you
>think, doesn't it?
>
>
I don't get this. If nothing changed why all the fsyncs. They are not
related to the locks are they? They are only releated to the log
flushes. Right?
I wonder if read-only transactions were aborted instead of commited what
would happen?
>
>
>>and it would come at a high cost in complexity and new bugs.
>>
>>
>>
>Our code wouldn't become that much more complex.
>
>
But will it become more BDB specific?
Let's face it. Over time there will be two camps form around the data
store. The use "a file system" folks and the use "a more sophisticated
DB" folks.
IMHO Both camps will be hurt if this imposes more specific access
patterns. I plan on having more than one physical schema to support the
same logical model. Will your changes impose even more special access
patterns? If so, where will the specific locking be handled? Would it
be handled inside, outside or both inside and outside of the current
trail framework? You won't promote it to the fs api right?
If you had a chance to apply and look at the all-in-one version of my
refactoring patch you may have noticed that I have two levels of
indirection in there.
One at fs api level and one at the DB access level. I convinced myself
that I can make a SQL back end that fits the current mold quite cleanly
at the DB access level. This would allow me to create a functional SQL
Back end fairly quickly. However I also want to be able to "go crazy"
and jump outside the current framework. The fs api indirection provides
more flexibility for this type of thing. The "DB access level"
indirection is very much predicated on the trail being the center of the
universe. If it is not, this layer may become obsolete for my purposes.
I have no doubt that you can make it cleaner and faster. But will it be
as flexible?
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 21 18:20:43 2003