Peter Samuelson wrote:
> [Blair Zajac]
>> 3) use base-36 digits and some way of atomically incrementing it
>> + sequential
>> + short
>> - need to write code to atomically increment the counter
>> a) use sqlite to store the current value
>> b) use yet another file that is atomically updated and write the code
>> that
>> does this
>
> I was thinking 3b. Why not? Is there a concern about extra network
> I/O round trips for SAN backends? A function to open, lock, read,
> increment, write, unlock, close, return the new value, sounds like
> about 15 lines of code, particularly if the function to increment a
> base-36 number already exists in BDB.
I looked through the fsfs code and it looks pretty straight forward, as there's
a lot of infrastructure already there to lock the filesystem for commits.
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?
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 19 19:33:59 2007