Daniel Rall wrote:
> On Tue, 19 Jun 2007, Justin Erenkrantz wrote:
>
>> On 6/19/07, Blair Zajac <blair@orcaware.com> wrote:
>>> The only thing is, I'd like to have a separate lock for updating the
>>> transaction
>>> current count then using the current filesystem lock. There's no reason
>>> to lock
>>> the filesystem for a commit while incrementing the transaction counter.
>>>
>>> So I'm thinking of having two new files:
>>>
>>> 1) transaction-current: holds the base-36 number
>>> 2) transaction-current-lock: holds the lock for incrementing
>>> transaction-current.
>>>
>>> Or maybe transaction-count and transaction-count-lock, or exen txn-count,
>>> txn-count-lock.
>>>
>>> Comments?
>> Isn't adding yet another file and yet another lockfile getting a tad
>> overkill? -- justin
>
> Yeah, you had me with (3b) up until there.
I gathered write statistics on the existing system that the new svn based system
will replace. We're seeing around 10 commits per second, getting up to 20
commits per second during busy parts of the day. So I'm concerned about sharing
the write lock for the commit process and just incrementing a transaction sequence.
I don't know how fast getting a lock, incrementing the counter and releasing it
will be, nor how much contention.
Does anybody have any sense? Is the write throughput high enough that it
warrants a separate write lock?
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 12 20:51:07 2007