[Cosmo-dev] Bug Roundup

[Bobby Rullo]

I'm not sure I like this whole try, fail, sleep, try business.

It would be easier, better, (IMHO, clearly :-) ) to synchronize  
around some object like an interned String of the absolute path.  
Example, in java-ish psuedocode:


public void saveItem(Item item, String absolutePath) {

	...stuff...

	absolutePath = absolutePath.intern();
	
	synchronize(absolutePath) {
                doWork();
         }

}


On Oct 3, 2006, at 12:04 PM, Randy Letness wrote:

> Brian Moseley wrote:
>> On 10/3/06, Randy Letness <randy at osafoundation.org> wrote:
>>>
>>> I guess the question is at what layer the retry logic should  
>>> occur.  We
>>> could retry a save at the dao layer, but then there are questions  
>>> like
>>> what happens when the first request did a MOVE?  In that case,
>>> shouldn't we return a not-found error?  That would mean the retry
>>> logic has to be at the dav layer.  I guess one thing we could add is
>>
>> is that really true though? couldn't the dao detect if the item had
>> been moved (eg its parent item is no longer the same)? it could also
>> detect if the item had been deleted, right? there's a small number of
>> states the item could be in that would require logic other than
>> "overwrite the change that was just made".
>>
> Yeah but this all assumes a hierarchical data model.  What about  
> changing
> an item's name?  In dav, that means moving, but what about in other  
> protocols?
> I agree with what you suggested.  We should catch the exception,  
> log it, and
> return a 500 minus the nasty stack trace.  Then we can see how  
> often this
> happens and figure out a solution.
>
> -Randy
> _______________________________________________
> cosmo-dev mailing list
> cosmo-dev at lists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev