Malcolm Rowe wrote:
> On Wed, Sep 13, 2006 at 07:29:33PM +0530, Kamesh Jayachandran wrote:
>
>>> To be fair, I think Kamesh suggested at one stage that we persist the
>>> state to disk at transaction-close time, though he didn't explain how
>>> we'd ensure cache coherency, should the same transaction be opened
>>> simultaneously by more than one process.
>>>
>>>
>> Malcom,
>> My point is this implementation(disk-based-hash) is for
>> convenience(accumulating the data to be written to sqlite), not meant to
>> be shared across processes, so it need not be written to disk.
>> Nothing to worry about cache coherency.
>>
>>
>
> Kamesh,
>
> Our API guarantees that the following scenario must work.
>
> Process 1: Create new transaction (Tx1)
> Set properties (including mergeinfo properties)
>
> Process 2: Open transaction Tx1
> Query (mergeinfo) properties set by process 1
>
> Process 1: (Continue to work with still-open transaction Tx1)
>
> How do you propose to support that in your design?
>
I would like to make one thing clear here.
Today we have mergeinfo in 2 places.
1. in proplist (Which should be sufficient for the case you mentioned above)
2. in mergeinfo hash used for convenience not meant to be used by
anyother process other than the one that creates it. This mergeinfo hash
is short lived entity gets deleted upon successful commit of the txn.
Hope I made it clear.
With regards
Kamesh Jayachandran
> Regards,
> Malcolm
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 13 20:45:46 2006