On Thu, Sep 14, 2006 at 12:15:49AM +0530, Kamesh Jayachandran wrote:
> >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.
>
Yes, and if you aren't ensuring coherency between the hash and the
proplist, how do ensure that the processes above see the same view of the
transaction? Or, if you're doing write-through on the hash->proplist,
how do you invalidate process 1's existing cache when process 2 makes
a change to the hash?
I should point out that this isn't just theoretical - ra_dav issues
many (potentially overlapping) requests in the lifetime of a single
Subversion transaction, and these may end up being serviced by different
httpd processes.
Any design that requires me to know whether other processes might be
modifying the transaction I'm working on before I can decide whether
to do a query using a fast-but-possibly-out-of-date in-memory hash or
a slower-but-correct on-disk proplist is terminally broken, sorry.
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 21:07:22 2006