Malcolm Rowe wrote:
> Hi Blair,
>
> (I've been on holiday recently, so I probably missed any discussion of this.)
>
> On Fri, Jun 15, 2007 at 04:53:45PM -0700, blair@tigris.org wrote:
>> Make the FSFS backend do a much better job of generating unique,
>> unused transaction names. This will help in long-running
>> transactions.
>>
>> * subversion/include/svn_fs.h:
>> Add a note on transaction name generation and how the BDB and FSFS
>> backends generate transaction names and how transaction name reuse
>> could occur for each backend.
>>
>
> Not that I disagree with this change at all, but I'm curious as to what
> sparked it? As far as I was aware, we hadn't guaranteed that
> transaction names weren't reused before - when does it make a difference?
>
> Regards,
> Malcolm
We're writing a client/server asset metadata management system using the svn
filesystem as a backend and exposing the ability for clients to open long lived
transactions, and either commit or roll them back depending upon the clients
ability to get some unrelated work done. The clients have access to the
svn_fs.h api through Ice (www.zeroc.com) and when I ran multiple copies of my
test suite, I would get failures, when running only one test suite would succeed.
The test suite would test the ability of a remote client to open a transaction,
roll it back, then attempt to roll it back again to check for an expected
failure. I wasn't seeing the expected failure when I was running multiple
simultaneous test suites, and realized that a second client had opened a new
transaction in between the 1st and 2nd rollback, hence there was something to
rollback.
The system I'm designing allows multiple clients to work in the same
transaction, but this led me to realizing that while the client has a
transaction name to work with, it doesn't assure the client that it's the same
transaction it opened, as some other process could have rolled it back and
opened a new one.
So I wanted a best effort to have transaction names be new names and not
potentially reused names.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jun 18 19:38:09 2007